[vlc-devel] vlc: svn commit r21814 (jb)

[Rémi Denis-Courmont]

Le Saturday 08 September 2007 17:25:28 Damien Fouilleul, vous avez écrit :
> In the absolute, I don't disagree with you. Unfortunately, when you feed
> hundreds MPTS or SPTS to an EdgeQam, i.e gigabits of data, out of order
> packets just cannot be reordered and are just dropped, the local network
> must be configured in such a way that packets are routed in a
> predictable matter (ever heard of MPLS ?).

Yeah, and surely you will be using the VLC GUI to set such a beast up!
Seriously...

My point is that if we keep UDP in the sout panel, people will keep using UDP 
while they should be using RTP.

> Anyway, in those conditions, 
> RTP does not provide any advantage over raw UDP. btw, in most cases,
> RTP's advantage isn't really about reordering, but timestamping, as late
> packets can be dropped early by any router in a the network path, thus
> avoid unnecessary congestion in low bandwidth networks, such as GPRS,
> etc...

I disagree.
The network is not supposed to do deep packet inspection to drop packets. 
There is something very idiotic in such an architecture. Besides, packets 
will most of the time not be late, so that will be of little help to fight 
congestion.

If you have a congested link, you'd normally report the problem through 
RTCP-RR so the server adapts the bitrate. VLC does not implement that though.

Certainly the RTP timestamp is of utmost importance on the receiver... 
normally. My point is, if you use raw UDP, you are most likely conveying TS 
or something similar. In that case, you'd ignore the RTP timestamp if you 
used RTP; only the sequence number would be of interest from the RTP header.

-- 
Rémi Denis-Courmont