[rtmpdump] Need help with rtmpdump url parser
Howard Chu
hyc at highlandsun.com
Fri Dec 16 11:05:40 CET 2011
Petr Pisar wrote:
> On Fri, Dec 16, 2011 at 02:46:34AM -0600, Steven Penny wrote:
>> On Fri, Dec 16, 2011 at 2:25 AM, Petr Pisar wrote:
>>> "rtmp://foo:1935 app=blah/blah playpath=x/y/zzz" is not a valid URI
>>> (because of the space characters).
>>
>> Wrong.
>>
> I don't think so:<http://tools.ietf.org/html/rfc3986#appendix-A>.
>
>>> AFAIK there is no rtmp URI schema standard.
>>
>> Wrong.
>>
> Please link to specification.
>
>>> What about abadone this spacy hack and introduce new format that will be
>>> formally URI (or URL more precisly). E.g.
>>> "rtmp://foo:1935/?app=blah/blah&playpath=x/y/zzz".
>>
>> No.
>>
>> From http://rtmpdump.mplayerhq.hu/librtmp.3.html:
>
> This is self-made specification by librtmp. And I state the librtmp
> specification is wrong becuase the string is not URI per RFC3986, thus you
> cannot pass it to compliant software (even rtmpdump does not honor it). And
> this is what this thread is about.
Since I wrote the librtmp support for mplayer, ffmpeg, VLC, and XBMC, I can
assure you that this format works with all of the above.
rtmpdump was written before this API was added to librtmp, so it does not
support it. It wasn't deemed a worthwhile use of time to update it.
You cannot device a legitimate parameterization scheme for the librtmp
parameters that will not clash with the existing parameters in the original
RTMP URL and that will be intelligible for typing by hand.
> Even librtmp(3) does not specify when additional parametres are needed and when
> the leading URL-like word is unambiguous which makes the un-parametrized
> string effectively unuasable.
Bummer for you.
More information about the rtmpdump
mailing list