[linux-dvb] Re: video pts differences on dvb-t in the uk

[Måns Rullgård <mru@mru.ath.cx>]

Torgeir Veimo <torgeir@pobox.com> writes:

> On Sun, 2004-10-10 at 19:07 +0200, Måns Rullgård wrote:
>> 
>> > But surely the difference should be detectable in some way? I think the
>> > difference is less on some channels (TMF, some news channel). I delay
>> > video constantly by 160ms to compensate for this, but automating it
>> > would be preferable.
>> 
>> Are the PTS values offset from the true values?  Or are you using some
>> player that doesn't use PTS for synchronization?  Both sound pretty
>> broken to me.
>
> I'm not too familiar with mpeg2 and a/v pts.. I see the problems with
> both xawtv and vdr's softdevice. I believe the correct term isdvb
> transmission audio preload time? Is there any such thing in dvb-t
> transmission headers?

Normally, audio and video streams have regular PTS values indicating
the correct time to present (display or play through speakers) the
frame or sample immediately following the timestamp.  The timestamps
for all streams are in terms of the clock defined by the PCR values.
Typically, the PCR values are used with a PLL to synchronize a local
clock with the stream clock.  If the audio and video output devices
use the stream clock and the PTS values to determine playback time,
the audio and video will be perfectly synchronized.  If the audio
packet with a given PTS arrives later than the corresponding video
packet, the video must be buffered for some time.  If the difference
is too large, the buffer will overflow, and there will be skips in the
video.  Making the buffer larger will cure this.  The real problem
happens if packets arrive with PTS in the past, i.e. the PTS value is
less than the PCR at the time of arrival.  This is essentially asking
to play the content (audio or video) before it has arrived.  The
difficulty in achieving this should be obvious.  If it is known in
advance that timestamps will be late in this manner, one can apply a
constant offset to the PCR to compensate.  Maybe this is what you are
doing.

This all sounds simple enough, until one tries to actually do it.
Displaying video frames at the correct time is quite easy.  The
problem is with the audio.  The DAC in the sound card is driven by a
crystal of a fixed frequency, and in typical PC sound cards this
frequency is often slightly incorrect.  An error of 0.01% would result
in a drift of about 0.36 seconds per hour.  Since the frequency of the
DAC can't be adjusted, the only solution is to resample the incoming
audio to match the output frequency.  The problem here is that
resampling by such a small amount is rather difficult.  A hardware
MPEG decoder might lock the DAC clock against the stream clock to
avoid the problem.

-- 
Måns Rullgård
mru@mru.ath.cx