[vlc-devel] commit: Remove non-sensical NPT c omputation code from c9569b35. ( Rémi Den is- Courmont )

[Rémi Denis-Courmont]

Le lundi 21 juillet 2008 15:27:52 Ross Finlayson, vous avez écrit :
> No - what you get from the RTP stream are presentation times, and
> that is *all* you get from the RTP stream.  (Note, however, that
> these presentation times are not necessarily monotonic - e.g., if the
> stream is MPEG-2 streams with B-frames.)  These presentation times
> were generated by the server's clock; *however*, there is no
> guarantee that these times are aligned at all with the receiver's
> 'wall-clock time'.  I.e., there is no guarantee that the server is
> generating times that are in sync with 'real world time'.

RTP timestamps are "derived from a clock that increments monotonically and 
linearly in time to allow synchronization and jitter calculations". Since the 
VLC clock also increments monotonically and linearly (at 1MHz). Hence, let 
alone network jitter, the RTP timestamp and VLC clock are correlated through 
an affine transformation. The whole point of the VLC input synchronization is 
to estimate this transformation, and the jitter, and cache and resample as 
required. For historical reasons, VLC uses the MPEG terminology (PCR, PTS, 
DTS), but that's beyond the point.

Furthermore, an RTSP server is supposed to scale the RTP timestamp according 
to the RTP frequency and the RTSP Speed (1.0 by default), hence the affine 
slope is bound to be close to 1, unless the hardware clock is totally broken.

In practice, VLC needs to use the RT*C*P timestamps as the reference so that 
multiple RTP streams can be synchronized. But there is no assumption about 
that being equal to the wall clock. In fact, most VLC demuxers start counting 
the PTS from 0, rather than "current time". And the VLC clock starts from an 
arbitrary point in the past (e.g. the system boot on Windows and Linux).

> (Even though the times included in RTCP reports are in the Network
> Time Protocol (NTP) time *format*, they are not guaranteed to
> actually be NTP-synced times.  This is apparently what is happening
> with your QTSS stream, if you've found that the received presentation
> times are not aligned with VLC's wall clock.)

I have to disagree. Of course, there will be an arbitrary offset between the 
RTCP timestamps, and the VLC clock. But the RTP timestamps and the VLC clock 
will increase at almost the same speed (i.e. the slope of the affine 
transformation).

-- 
Rémi Denis-Courmont
http://www.remlab.net/