[vlc-devel] VLC 0.8.6 end of support

[Rémi Denis-Courmont]

On Wed, 3 Sep 2008 10:05:37 +0200, "Marian Ďurkovič" <md at bts.sk> wrote:
>> And the old "stupid" RTP code did exactly that, feed the packet with
>> varying delay, hence at the wrong time - due to the overly simplistic
>> re-ordering algorithm. No better than the current code. Of course, if
>> you
>> receive packet at regular interval, and at high frequency (as is 
>> typical from a TS stream), the jitter will be averaged quite well, and 
>> the synchro will work around irregularities. In other words, both the 
>> old and new RTP receivers are wrong, and abusing the VLC synchro. Only 
>> proper jitter calculation in VLC 1.0 will fix that.
> 
> Sorry, but most (if not all) MPEG-TS over RTP clients work exactly the
> same way as the old RTP code. MPEG-TS demuxers (often implemented in HW)
> are prepared to reconstruct timing and synchronize it's internal clock
> just by looking at the information contained in the TS, which is exactly
> what VLC is doing. PCR needs to be present in the TS at least once per
> 100 msec, and this is pretty much sufficient for the clock
synchronization
> purposes. Afterall, you need this functionality in synchro when you want
> to keep raw UDP support.

Yeah and VLC should add a fairly constant delay for the clock synchro to
work. Not something the old RTP code did (nor the new RTP code so far,
indeed). It would be gullible to believe that the old 100ms check did that.

> You also need to keep in mind, that RTP timestamps could not be trusted
is
> MPEG-TS case.

2. Encapsulation of MPEG System and Transport Streams

   Each RTP packet will contain a timestamp derived from the sender's
   90KHz clock reference.  This clock is synchronized to the system
   stream Program Clock Reference (PCR) or System Clock Reference (SCR)
   and represents the target transmission time of the first byte of the
   packet payload.  The RTP timestamp will not be passed to the MPEG
   decoder.  This use of the timestamp is somewhat different than
   normally is the case in RTP, in that it is not considered to be the
   media display or presentation timestamp. The primary purposes of the
   RTP timestamp will be to estimate and reduce any network-induced
   jitter and to synchronize relative time drift between the transmitter
   and receiver.

> There are even professional encoders that simply don't set that field
> in RTP headers (it's zero all the time),

That would definitely not be "professional", as in professional-grade or
professional-quality for sure. And that would not be RTP (see above)
either.

Please buy "professional [de]coders" and stop bitching about FREE
OPEN-SOURCE VLC.

> and in case you need to create RTP from raw UDP,
> you can at best guess/interpolate the RTP timestamps for packets without
PCR.

That's OK. Assuming the input is properly synchronized, this will kind of
work.

> If you plan to implement "proper jitter calculation" for VLC1.0,
> you'll just significantly reduce compatibility with zero benefit to the
user...

Oh yeah? We have lots of users complaining about VLC excessive input
delays.

-- 
Rémi Denis-Courmont