[FFmpeg-devel] [rtsp/rtp] update rtp to support rfc3550

[Martin Storsjö]

On Thu, 15 Apr 2010, Luca Barbato wrote:

> I'd rather keep the logic as is and keep dss happy either by having a
> quirk for it or by using a fallback.

Interestingly enough, on OS X, the method of letting the OS choose a port 
randomly for both protocols actually gives consecutive port numbers, as 
long as nobody else opens sockets inbetween. :-)



As a related note, I finally found another youtube rtsp url that seemed to 
work, and tried rfc3550 on it, and got this:

SETUP rtsp://v2.cache5.c.youtube.com:554/CiQLENy73wIaGwnWCCh2nek6MRMYESARFEgGUghzdGFuZGFyZAw=/0/0/0/video.3gp/trackID=2 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=55444-6131
CSeq: 3

RTSP/1.0 461 Unsupported Transport
CSeq: 3
Server: Google RTSP 1.0


So this server doesn't support unmatched RTP ports either. gst-rtsp-server 
seems to support it just fine, though.


And on the subject of strategies for allocating UDP ports, here's how 
gstreamer is doing it:
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n1332

That is, the algorithm is roughly this:
- Bind a UDP socket without specifying a port, letting the OS randomly 
allocate a port
- If the port happens to be odd, close it and try opening the next one 
instead
- If unable to open the port, do port += 2 and try again
- When able to open the RTP port, try to open the next one for RTCP
- If unable to open the RTCP port, close the RTP one too, do port += 2 and 
retry
- Abort if unable to allocate ports after 20 tries.

So it's not as easy as simply relying on RFC 3550, but should be quite 
failure proof.


// Martin