[FFmpeg-devel] FFMPEG RTSP parameters support

[Ronald S. Bultje]

Hi,

On Sun, Nov 14, 2010 at 4:30 PM, Martin Storsj? <martin at martin.st> wrote:
> 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.

Actually, you're right, the trackID=1 is confusing me. Isn't that the
rtp control URI appendix?

Ronald