[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