[vlc-devel] VLC 0.8.6 end of support

[Rémi Denis-Courmont]

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. The VLC RTP/TS sender is not doing anything 
fancy. Also the receiver is ignoring the PTS anyway. Compare:

 450 /* Send a packet to decoder */
 451 static void codec_decode (demux_t *demux, void *data, block_t *block)
 452 {
 453     if (data)
 454     {
 455         block->i_dts = 0; /* RTP does not specify this */
 456         es_out_Control (demux->out, ES_OUT_SET_PCR,
 457                         block->i_pts - demux->p_sys->caching * 1000);
 458         es_out_Send (demux->out, (es_out_id_t *)data, block);
 459     }
 460     else
 461         block_Release (block);
 462 }

and:

 477 /* Send a packet to a chained demuxer */
 478 static void stream_decode (demux_t *demux, void *data, block_t *block)
 479 {
 480     if (data)
 481         stream_DemuxSend ((stream_t *)data, block);
 482     else
 483         block_Release (block);
 484     (void)demux;
 485 }

The stream_Demux*() code does not deal with the clock either. In other words, 
I cannot make sense of your bug report. 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.

If you are not happy with the release policy, you are free to fork 0.8.6i and 
maintain it yourself. I am fed up with professionals, semi-professionals, and 
individuals alike bitching about how we - _*VOLUNTEERS*_ - deal with VLC 
maintenance.

> They could always coexist with some config option

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

I am not going to explain to those folks trying to use PCM over RTP or RTP 
over DCCP that they should use some obscure option for this. Especially as 
they will not know whom to ask from and where to look.

> - we already have no-sap-parse for disabling VLC's internal RTP module

No. --sap-parse disables the SAP parser from the SAP discovery module. And 
most _normal_ SAP users don't know about this option.

> and sending 
> everything to live555. I could also imagine handling MPEG-TS by the
> previous code and all other RTP elementary streams with the new code
> - after all, MPEG-TS over RTP is significantly different beast than
> RTP-muxed elementary streams.

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.

> 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.

> 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?

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary