[mythtv] 8902 HD transcode => MPEG4 --> a/v out of sync
Jesse Crews
jcrews at gridlox.net
Thu Feb 9 16:53:39 UTC 2006
Quoting Geoffrey Hausheer <mythtv0368 at phracturedblue.com>:
> On 2/8/06, Jesse Crews wrote:
>> Hi,
>>
>> I've been having an issue with transcoding anything recorded from a
>> particular ATSC transponder (NBC affiiliate, OTA). The output always
>> shows the video somewhere around .5 seconds earlier than the audio.
>> Maybe even an entire second.
> I have seen this on our local PBS-HD affiliate occasionally, though in
> my case it is actuallly something withe the stream from the card, as
> even mplayer plays the stream off, and I've looked at the PTS values,
> and the a/v really is off in the original. Are you sure that it is
> the transcoder that is doing it? Have you tried playing it with
> mplayer?
>
Yes. Mplayer works fine, as does mythfrontend.
>> I did run mythtranscode with mpeg2fix process messages enabled, and
>> nothing came out.
> Are you trying mpeg2->mpeg4 or mpeg2->mpeg2 (mpeg2fix can only handle
> the latter) or was this just an experiment?
Oops, something got mixed up in my mind after reading transcode.cpp. :)
It's mpeg2->mpeg4. mpeg2fix is not actually being created here.
> What do you mean by 'nothing came out'? You'd need to tell me what
> the failure is, and perhaps run with '-v all' (this will be huge, so
> zip it up and send it to me off-list)
>
no pertinent messages. I'm creating mythtranscode -v all ... now. I'll
send it to you when it's finished.
>> When I play the file back via mythfrontend, it also throws the guess
>> message, but the A/V sync is correct.
> Odd...can mplayer handle it correctly?
Yes. There are no a/v related warnings in -v 3, and no warnings when
invoked normally.
>> What could be different in the
>> way that NVP calls are being utiized by mythfrontend vs. mpeg2fix in
>> mythtranscode?
> Well, they really do decode completely differently, so that isn't an
> easy question to answer.
>
The question as stated is no longer valid.
Anything below doesn't seem to matter in my case.
>> There are some comments in there about how some
>> operations being done "might not be a good idea."
> There are a lot of corner cases that are handled in mpeg2fix, and I
> need to use some heuristics to make them work right. They may not
> work in every situation though.
>
>> Should I add some messages to print aPTS, vPTS, PCR (really, whatever
>> the PCR is equivalent to in a TS), and try to see where drift is being
>> introduced?
> using '-v all' with mythtranscode will print out enough PTS info to be
> useful (we don't pay attention to the SCR in mythtranscode (though
> maybe we should) and there isn't currently any code to print it out.
>
>>
>> There does appear to be some logic to figure out if the above values
>> are wrong, and I recieved no such messages.
>>
> It depends on how you run mythtranscode as to whether those messages
> will print. by default, only 'MPF_IMPORTANT (equivalent to
> VB_IMPORTANT) will print out). We do handle all sorts of corruption
> cases, and I can probably handle yours too with a bit of patience and
> some debugging.
>
> .Geoff
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> !DSPAM:1,43eab55422721241580238!
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: PGP Digital Signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060209/6c665734/attachment.pgp
More information about the mythtv-dev
mailing list