[FFmpeg-devel] FFMPEG RTSP parameters support

[Martin Storsjö]

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.

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

Do you have any RTSP client that manages to play these URLs properly? 
Wireshark it and compare with what we do and change it appropriately.

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.

// Martin