[vlc-devel] VLC 0.8.6 end of support

[Marian Ďurkovič]

On Tue, 2 Sep 2008 23:15:06 +0300, Rémi Denis-Courmont wrote
> Le mardi 2 septembre 2008 14:16:39 Marian Ďurkovič, vous avez écrit :
> > On Tue, Sep 02, 2008 at 12:33:27PM +0200, Rémi Denis-Courmont wrote:
> > > It is perfectly usable to me.
> >
> > Try any commercial MPEG-TS over RTP source, VLS, or e.g my rtpstream
> > utility. No sound, log full of "PTS out of range" etc. The new RTP
> > module doesn't cooperate with clock synchro correctly, and seem
> > to only work when streaming from VLC to VLC. (BTW, doesn't it accidentially
> > feed RTP timestamps to the synchro?)
> 
> Well, if it does work with VLC and not some other source , I have to 
> assume that the other source is broken. 

Hey, do you want to say that all sattelite TV stations are using broken
MPEG-TS encoders ?! VLS is not doing anything else, than taking the
corresponding TS packets out of the DVB-S transponder and sending them
out to the network. Unlike VLC, VLS does *not* reconstruct the PCRs, 
does not remux TS, it just selects the TS packets for required PIDs
and sends them out. So the stream from VLS is exactly that MPEG-TS
which the TV station produces for broadcast (production) quality!
The same is true for my rtpstream - it takes what it gets from the encoder
and adds 12 bytes of RTP header to each packet.
And now comes the surprise: VLC 0.9.x plays the raw UDP from the encoder,
but not the *identical* stream with RTP headers... Needless to say that
0.8.6 or mplayer have no problems here.

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.


> But that's what you get 
> anyway for filing "critical" obscure bugs right while we're wrapping 
> up a new release 
> (august) instead of when we asked for it. You've had two full months.

Which are obviously holidays at the universities....

> And you'll go to every VLC user to set the option right, right?

Better than not having an upgrade path at all...

> That's very much not true. The only difference with TS is that the RTP 
> timestamp is essentially ignored, and that's a matter for the codec, 
> not for RTP itself. Delay jitter computations and other statistics,
> RTP re-ordering work all the same with TS as with normal RTP formats.

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.  

> > In any case, for MPEG-TS over RTP we need to be sure that VLC executes
> > the special clock-synchro algorithm, which ensures that VLC's internal
> > reference clock is synchronized to the sender's clock.
> 
> That's a job for the VLC clock and TS demux. RTP is NOT involved.

RTP *is* involved. If the RTP module sends packets to the rest of input chain at
wrong time points, the whole timing is screwed and unrepairable. That's we
we're seeing right now I'm afraid.

> 
> > For the same reasons, prebuffering needs to be disabled for both UDP and
> > RTP, which doesn't seem to be the case again with 0.9.x. With prebuffering
> > (which is kB based and not time-based), VBR streams confuse VLC's internal
> > reference clock to the point that it starts up/downsampling or drops audio
> > packets at big scene changes.
> 
> Precisely, the *old* RTP access had prebufferring, and the new one 
> does not. And UDP still has it - unchanged. What are you whining about?

Please have a look at the 0.8.6 UDP/RTP access. For both RTP as well as
well as raw UDP, the access was setting:

p_access->info.b_prebuffered = VLC_TRUE;

This was a signal to the lower parts of the input chain to disable size-driven
prebuffering after the access and before clock synchro. You apparently deleted
this and it needs to be restored for raw UDP.
The RTP prebuffering was there for completely different purpose, and it was
time-driven and not size-driven.


      M.