FF card A/V sync suggestion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Udo Richter wrote:
> Tero Siironen wrote:
>> Here is a 3 minute clip from the episode of Lost I told earlier.
>> http://kotisivu.suomi.net/izero/lost.tar
>>
>> 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
> 
> I've checked your recording. Lost "The other 48 days" - surely one of
> the worst episodes for me too, because the fade-to-black on every day
> break.
> 
> Your recording however runs relatively fine on my FF (r1.6 firmware
> f22623) card. There's noticeable audio stuttering after the
> fade-to-black scenes, but audio desync is only small, though noticeable.
> 
> Demultiplexing with ProjectX throws 11649 of errors like this:
> 
> !> error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 /
> true / false)
> !> error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 /
> true / false)
> 
> pos is changing, the rest seems always the same.
> 
> I then re-muxed the elementary streams and converted them back to VDR,
> and the resulting video played fine again. So this issue seems to be
> some problem on the PES packaging layer.
> 
> In contrast, my recording issue cannot be fixed by re-muxing, and has
> more noticeable audio desync, its probably a totally different issue.
> The dev's already have a sample file.
> 

It is postulated that vdr takes whatever it gets and shoves it into the playback
buffers of the a/v decoder in whatever order it is in. In live TV this is
rate-limited meaning the clocking source is the network and the network
transmits at whatever rate it needs to and the decoder decodes it.  So, let us
say that time is "x". If video is transmitted faster than rate "x", and audio
also is transmitted faster than time "x", then we get a xrun. I think that's
understood. But, if video is transmitted faster, then slower, then faster, then
slower etc, but drifts around time "x", and is not sent to the decoder at any
other speed than "x", then the decoder gets a constant smooth stream. Because if
it takes x+3 ms to play something, the input stream on livetv won't overfill its
buffer because the next run will be x-3 ms and so the extra time is made up.
This is very easily seen with variable framerates and bitrates. Audio also might
be doing the same thing, where it send at spurts rather than a steady stream.
Now if audio and video are both spurting along, where do you find a common time?

IRL, time is constant. But on playback if vdr doesn't clock its data, then
desync is quite possible. For example, if there's nothing to "change" for a few
video frames, because they're using "stack" compression they won't send an empty
frame. So, consider this blackout time in "Lost". The theory is that problems
are occurring because they're not sending empty null frames. Also, if they're
clocking on video, not audio. You will get your sync problems because you're
missing bits. Does VDR store the pcr pid in the recordings? Is the pcr used
during playback to clock the data?

Best Regards.



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux