[FFmpeg-devel] FFMPEG RTSP parameters support

[Martin Storsjö]

On Sun, 14 Nov 2010, Ronald S. Bultje wrote:

> On Sun, Nov 14, 2010 at 10:15 AM, Martin Storsj? <martin at martin.st> wrote:
> > On Sun, 14 Nov 2010, Stas Oskin wrote:
> >> I noticed an issue with FFMPEG, where it doesn't support parameters in RTSP
> >> control URI's, causing the SETUP request to fail.
> >
> > "Doesn't support" sounds like the wrong conclusion to me - I've never seen
> > any spec on how this should be handled, and what the code does at the
> > moment seems like a relatively sensible thing to do.
> >
> > Nevertheless, I've never seen an RTSP server actually support parameters
> > in the URL, so I've never been able to verify how the servers expect it to
> > be handled.
> 
> It's very normal, e.g. for session IDs or so.

Do you off-hand know any server/setup supporting it, where I could test 
it?

> >> For example:
> >> ffmpeg -i rtsp://192.168.0.150/loadtest.sdp?a=1<http://192.168.253.150/loadtest.sdp?a=1>
> >> or
> >> ffmpeg -i rtsp://192.168.0.150/loadtest.sdp?a=1&tcp<http://192.168.253.150/loadtest.sdp?a=1&tcp>(/udp/http)
> >>
> >> Will cause the request to fail with following error:
> >>
> >> [rtsp @ 0x1a13f470] method SETUP failed: 415 Unsupported Media Type
> >> rtsp://192.168.0.150/loadtest.sdp?a=1&tcp<http://192.168.253.150/loadtest.sdp?a=1&tcp>:
> >> Invalid data found when processing input
> >>
> >>
> >> I would like to add this and submit a patch - any idea what would the best
> >> place to start?
> 
> There is no solution. You can't give parameters a=1 in the URL if the
> server doesn't support that. The ?tcp is a hack and should become a
> commandline option (using AVClass/AVOptions) instead of an appendage
> to the URI, but nobody has done that so far.

The ?tcp stuff doesn't have anything to do with this issue - rtsp.c strips 
it out, so if you give an url ending in /loadtest.sdp?tcp, the url used in 
the RTSP requests will be /loadtest.sdp. If you have 
/loadtest.sdp?a=1&tcp, or /loadtest.sdp?tcp&a=1, the base url used in 
requests will be /loadtest.sdp?a=1.

> > Currently, we first strip out the libavformat specific options
> > (tcp/udp/http) and leave the rest as base url. So all
> > OPTIONS/DESCRIBE/SETUP/PLAY methods are called with that url. For the
> > SETUP requests, I'm not sure in which way the server expects the
> > parameters to be passed, since we append the track number. I can think
> > of a few different options:
> >
> > - rtsp://1.2.3.4/stream.sdp?a=1/trackID=1
> > - rtsp://1.2.3.4/stream.sdp/trackID=1?a=1
> > - rtsp://1.2.3.4/stream.sdp/trackID=1
> >
> > The first one is what we do now (as far as I know), I guess one of the
> > other ones is what this server requires. Can you find any standard
> > document saying that this way of handling it (whichever the server wants)
> > really is the one mandated by some standard, too? Otherwise we might
> > encounter some other server wanting the parameters formatted in some other
> > way at some point.
> 
> The second one is what we use right now if we want custom options, and
> the third is what it should be if that was the original URI in e.g.
> the playlist.

No, now you're mixing things up. What libavformat/rtsp.c currently does is 
the first one. Custom options such as ?tcp doesn't have anything to do 
with that.

If we specify an url such as rtsp://1.2.3.4/foo.sdp?tcp&a=1, we strip out 
the tcp option and use rtsp://1.2.3.4/foo.sdp?a=1 as base url. This url is 
used in the OPTIONS and DESCRIBE methods. In the SETUP methods, we append 
the track ID as specified in the SDP, e.g. /trackID=1. What the code 
currently does, is that it appends this straight on to the base url, so 
that it becomes /foo.sdp?a=1/trackID=1. This probably isn't right, and I'm 
not sure where the a=1 parameter fits into the picture (left out totally 
or if it is appended after trackID=1.

// Martin