[FFmpeg-devel] [PATCH] rtsp - alternate protocol

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
>>> So, can anyone explain what's the supposed behaviour of url_split()? 
>>> Which testcase was fixed by r10775?
>> iam not sure but if i guess i think it prevents ?tcp from ending in the
>> hostname
> 
> heres a attempt to fix it (completely untested, theres a good chance it
> contains trivial mistakes but ill comit it if noone points at a problem
> soon *g*)
[...]

I tried your patch, and it obviously fixes option parsing in rtsp.c 
(with your patch applied, the "?..." is back in "path"). I do not know 
if it re-introduce the regression cured by r10775, because I did not 
understand the testcase...

However, after applying your patch rtsp.c still has problems if options 
are passed in the URL: such options are now correctly recognised, but 
they are not removed from the URL, so the RTSP server sees requests for 
URLS like "rtsp://localhost:5454/test1-rtsp.mpg?tcp" instead of 
"rtsp://localhost:5454/test1-rtsp.mpg".

This happens because the code in rtsp_read_header() removes the options 
from the "path" variable (while parsing them), but does not remove the 
options from "s->filename"; RTSP requests are forged based on 
s->filename, not on path... I did not notice this problem before, 
because I focused on the first one (fixed by your patch), and my fix for 
the first problem incidentally fixed the second one.
I see three different solutions to the second problem (options not 
removed from the URL in RTSP commands):
1) changing "option_list = strchr(path, '?');" in "option_list = 
strchr(s->filename, '?');", as my original patch did.
2) using path instead of "s->filename" in the RTSP packets (I still have 
to check how invasive this patch would be)
3) modify s->filename removing the options from it too...


			Thanks,
				Luca