[mythtv-users] Sound a second behind video

[Michael T. Dean]

On 03/12/2008 07:58 PM, Mark Hutchinson wrote:
> mplayer is fine with the file.
> The Internal player audio is off.
> Please, try it for yourself.
> It starts with 3 commercials. The third one is two kids talking.  It  
> is obvious that the audio is off with the internal player.
>
> Here is  the file.
> http://onnow.net/syncprob.mpg
> Just do a wget on it.

It plays fine (and in sync) on my system.  Even in the 3rd (Life Cereal) 
and 4th (Caltrate) commercials and the show itself where I could see the 
faces of the people speaking.

When I played it without a seektable, it was slightly out of sync--aobut 
-80ms or so.  I didn't even notice it the first time I played through 
it.  Then, I built the seektable with:

mythcommflag -c 9999 -s '2008-03-11 16:00:00' --rebuild

(knowing that was very likely to create an invalid seektable because the 
file is MPEG-2) and it played back with a larger offset--maybe -150 to 
-250ms.  This time it was definitely large enough to see.  Then, I 
cleared the seektable with:

delete from recordedseek where chanid = '9999' and starttime = 
'2008-03-11 16:00:00';

And played it again and this time could see the 100ms offset (once you 
see an A/V sync offset, the threshold at which you notice an offset 
plummets).  Then, I rebuilt the seektable with:

mythtranscode --mpeg2 --buildindex --allkeys -c 9999 -s '2008-03-11 
16:00:00'

(which is the proper way to build a seektable for an MPEG-2 recording) 
and it played back perfectly, with no sync offset.

So, I would recommend you start by manually deleting the seektable then 
build a seektable using mythtranscode, as above (but fix the chanid and 
starttime for the recording you're testing).  If you get good audio at 
that point, then you at least have a workaround (i.e. can set up a user 
job to rebuild the seektable for SDTV recordings).  Just make sure--for 
completeness of testing--you manually delete the seektable entries 
before rebuilding the seektable with mythtranscode.  You should see 
marks in the recordedseek table of type 9.

I'm really starting to think it's just the seektable as that would cause 
the behavior you and the reporter of #4893 are seeing with regard to 
seeking ("skipping") and can affect audio sync, too.  I'm sure someone 
else (Chris Pinkham, perhaps?) could give you more information about 
what's different between the during-recording seektable building for 
firewire recordings and for non firewire recordings.  Or, if nothing, 
perhaps it's something about that stream that tricks the seektable 
building code into thinking it shouldn't use the MPEG-2 handling code.  
I will say, though, that it seems the recording has many varying 
keyframe distances (from 9, 12, 15, 18, 24, 27, 30 frames).  This may be 
confusing the built-in seektable building code.

If clearing/rebuilding the seektable does fix it, I recommend dumping 
the seektable for one of your other affected recordings.  You can do it 
by just replacing the delete in the SQL above with a "select *".  Might 
want to do a "tee /tmp/seektable.txt" (no quotes) first, to log the 
output.  It may be useful in helping debug the issue.

Anyway, if the seektable clearing the rebuilding doesn't help, perhaps 
there's a delay in your audio processing (on your receiver/TV).  It's 
possible it could appear only on SDTV if the SDTV audio is sent to the 
receiver in a different format or something.

Thanks (and good luck),
Mike