[mythtv-users] Sound a second behind video

[Mark Hutchinson]

On 12-Mar-08, at 9:31 PM, Michael T. Dean wrote:

> On 03/12/2008 11:11 PM, Mark Hutchinson wrote:
>> On 12-Mar-08, at 9:02 PM, Michael T. Dean wrote:
>>> On 03/12/2008 07:58 PM, Mark Hutchinson wrote:
>>>
>>>> mplayer is fine with the file.
>>>> The Internal player audio is off.
>>> 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.
> ...
>>> 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.
>> As a standard video
>
> I played it as a recording.
>
>> though, using Internal player, would there be a
>> seek table?
>>
>
> There would be if you build one with the --video argument to
> mythtranscode (see the --help output).  (Note that --video is also  
> valid
> for mythcommflag, but we've already established you don't want to  
> use it
> to build a seektable for these MPEG-2 videos.)
>
>> Does this still not indicate a bug?  I see this behavior too while
>> watching live TV on SD. Fine on HD though from the same firewire  
>> device.
>
> Ideally ffmpeg code would be able to play it even without a seektable.
> However, with a good seektable, we have information that's extremely
> useful at playback time (allowing a +7 second skip to skip 7 seconds  
> of
> video--whereas the same in a player without a seektable--such as  
> xine or
> MPlayer--can trigger a -60second to +120 second skip, depending on the
> video stream and the exact time when you hit the skip button and how
> much information is known about the video around that point--i.e. have
> you already played the section once and skipped back--and ...).   
> And, I
> would guess it would also be useful in frame delivery (but I have no
> proof of that).
>
> So, since you and others have found that ffplay doesn't work well  
> (and I
> just verified--in ffplay sound played almost a second before the video
> in the commercials, but was in sync during the show), it may be a  
> "bug"
> (or at least a type of stream not handled well by ffmpeg libraries).
> That doesn't mean that we can't play it back, though... :)
>
> If you can prove that you're getting a bad seektable during recording,
> we have something to fix.  Otherwise, we're probably at the mercy of  
> the
> ffmpeg devs.
Thanks!  I think it is a bad seek table during recording.  This was a  
standard scheduled recording.  With resulting bad playback and seek  
table issue.  If I am understanding you correctly.

I am a bit lacking in what it takes to fix this one.  Advice  
appreciated.