[vlc-devel] VLC 0.8.6 end of support
rem at videolan.org
Tue Sep 2 22:15:06 CEST 2008
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)
453 if (data)
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);
461 block_Release (block);
477 /* Send a packet to a chained demuxer */
478 static void stream_decode (demux_t *demux, void *data, block_t *block)
480 if (data)
481 stream_DemuxSend ((stream_t *)data, block);
483 block_Release (block);
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
> 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?
More information about the vlc-devel