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

Martin Storsjö martin
Fri Apr 16 22:53:07 CEST 2010


On Fri, 16 Apr 2010, Luca Barbato wrote:

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

Yeah, dss generally is more or less stalled as far as I've understood. 
Patching it in yourself could be more or less problematic, too, I'm not 
familiar enough with the codebase to comment on that.

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

Hmm, how would you fall back if the peer didn't work with rfc3550? For 
google rtsp that gives an error on the SETUP, one could simply retry with 
a new SETUP with a normal port pair, but if DSS simply gives OK but 
interprets it as something else than what was sent, we would have to redo 
the SETUP for that stream - is that ok within RTSP?

Also, if acting as a server, how do we know if it's appropriate to reply 
to a client's SETUP with a non-consecutive port pair?

Both with these questions in mind, and being primarily a DSS user, I'd 
prefer trying to allocate normal port pairs initially, if possible, and 
only then revert to unmatched pairs ? la rfc3550 if unable to get a 
working normal pair after a few attempts.

// Martin



More information about the ffmpeg-devel mailing list