[FFmpeg-devel] [rtsp/rtp] update rtp to support rfc3550
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. :-)
> 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:
> 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
> - 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
> - 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.
More information about the ffmpeg-devel