[FFmpeg-devel] [PATCH] rtsp - alternate protocol
Sat Dec 29 09:55:08 CET 2007
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
> 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
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...
More information about the ffmpeg-devel