[vlc-devel] VLC 0.8.6 end of support

[Rémi Denis-Courmont]

On Wed, 3 Sep 2008 11:10:00 +0200, Marian Ďurkovič <md at bts.sk> wrote:
> On Wed, Sep 03, 2008 at 10:42:32AM +0200, Rémi Denis-Courmont wrote:
>> 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.
> 
> Yes it did (modulo OS delays). If you don't believe it, put a printf()
> into the old RTP/UDP access :-) And most importantly, it ensured
> continual timing even in case of lost packet.
> 
> 
>> > 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.
> 
> You definitely won't fix that by "proper jitter calculation". Input delay
> could not be reduced even in lab environment with zero network jitter,
> since the real problem is in the PTS_DELAY hack.

For which both Fenrir and Pdherbemont seemed interesting in hunting.

For RTP a double de-jitter will be needed - the RTP access_demux needs to
estimate how long to wait for re-ordered packets

> Moreover, when you start computing jitter for every single IP packet
> instead of once per PCR, with HDTV streams you'll end up with ~2000
> computations per second instead of ~20. We already lack CPU cycles
> for h.264 streams, and such waste of CPU will really not help anyone.

We anyway need to compute the jitter for RTCP conformance. I doubt that RTP
processing is significant in any way.

-- 
Rémi Denis-Courmont