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

Luca Barbato lu_zero
Fri Apr 16 22:32:46 CEST 2010

On 04/16/2010 08:54 PM, Martin Storsj? wrote:
> 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. :-)

eh ^^;

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

so gst ffserver (now) and feng are fine, dss and google rtsp not =_=;

For google it's relatively easy to report and hopefully have them update
their server. For dss I'm afraid it will be quite a pain.

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

I guess we could copy gst's behaviour.

I'd change our ffrtsp to:
  - try with rtsp3550 first
  - fall back to the gst way of allocating ports on a failure

I'd make ffserver go the same way, so it would spend possibly less time
and resources while serving rfc3550 compliant receivers.



Luca Barbato

More information about the ffmpeg-devel mailing list