[vlc-devel] VLC 0.8.6 end of support

[Marian Ďurkovič]

On Wed, 03 Sep 2008 09:34:29 +0200, Rémi Denis-Courmont wrote
> On Tue, 2 Sep 2008 22:59:48 +0200, "Marian Ďurkovič" <md at bts.sk> wrote:
> > Unlike VLC, VLS does *not* reconstruct the PCRs,
> 
> That is a VLS bug...

WTF? VLS just passes the TS from DVB-S to IP, why it should mess with PCRs?
You're confusing PCRs with RTP timestamps. PCRs are *inside* the TS, they have
nothing to do with RTP.

> > So apparently, the new RTP module works with only one specific
> combination
> > of PCR interval, delta between PCRs and PTS and other TS parameters
> > as implemented by VLC's TS output muxer. When it gets anything else,
> > it breaks.
> 
> FOR THE LAST TIME: VLC does not use the RTP timestamp for TS. And fenrir's
> last RTP fix clearly did not change this.

Please read my statement once again. I said *nothing* about RTP timestamps, I
was speaking about PCRs. It's a parameter of TS muxer - delta between PCRs and
PTS. Without fenrir's fix, the RTP module didn't have any time left for decoding
and MPEG-TS from VLC worked just by coincidence - because VLC
TS mux uses much bigger PCR-PTS delta than professional encoders. 

> > Yep - except that elementary streams have their PTSs in RTP, so you can
> > basically do anything regarding the timing. I.e. even if you feed packets
> > down the chain at completely wrong intervals, PTS will ensure correct
> > display. With TS, VLC's synchro depends on precise timing - and if you
> > for example deliver packet with PCR at wrong time, synchro will shift
> > the reference clock to bogus values.
> 
> 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.

You also need to keep in mind, that RTP timestamps could not be trusted in
MPEG-TS case. There are even professional encoders that simply don't set that
field in RTP headers (it's zero all the time), and in case you need to create
RTP from raw UDP, you can at best guess/interpolate the RTP timestamps for
packets without PCR. If you plan to implement "proper jitter calculation" for
VLC1.0, you'll just significantly reduce compatibility with zero benefit to the
user...


     M.