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. _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
