[FFmpeg-devel] FFMPEG RTSP parameters support
Ronald S. Bultje
Sun Nov 14 15:50:23 CET 2010
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.
>> For example:
>> ffmpeg -i rtsp://192.168.0.150/loadtest.sdp?a=1<http://192.168.253.150/loadtest.sdp?a=1>
>> 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
>> 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.
> 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://220.127.116.11/stream.sdp?a=1/trackID=1
> - rtsp://18.104.22.168/stream.sdp/trackID=1?a=1
> - rtsp://22.214.171.124/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.
More information about the ffmpeg-devel