[FFmpeg-devel] [rfc] merge the applehttp-urlprotocol into main

[Martin Storsjö]

On Mon, 28 Feb 2011, Tomas H?rdin wrote:

> aviad rozenhek skrev 2011-02-28 11:39:
> > On Mon, Feb 28, 2011 at 00:40, Martin Storsj?<martin at martin.st>  wrote:
> >
> >> On Sun, 27 Feb 2011, Luca Barbato wrote:
> >>
> >>> - append "http://" so the url shouldn't be applehttp://http://
> >>
> >> I'm undecided about this. The applehttp://http:// URLs sure do look ugly,
> >> but without that, how would you specify to play a stream of this kind from
> >> a local file?
> >>
> >>
> > we could parse the *inner *url again to see if it has a protocol specifier,
> > and assume http if it doesnt [instead of assuming a file]
> > therefore this url
> > applehttp://xx.yy.zz.ww/abc/
> >              ----------------
> >              inner url part
> >
> > will be parsed as applehttp://http://xx.yy.zz.ww/abc/
> > while file urls can be specified explicitly, as in
> > applehttp://file://usr/files/myfile.m3u8
> >              ----------------------------
> >              inner url part
> 
> You can't nest URIs like that - please read RFC 3986 ( 
> http://www.ietf.org/rfc/rfc3986.txt ).
> 
> A better solution IMO would be to go the svn+ssh route - a plus sign. So 
> applehttp+file:/foo/bar/playlist.m3u8 for instance.

That might indeed be a better route. Although I don't think we currently 
can handle registering a protocol that will catch any 
applehttp+<whatever>://, at the moment we'd have to register the full 
applehttp+<whatever> as protocol name.

What would be a good way of handling this? Adding a flag to URLProtocol, 
where a protocol can signal that it can work as a base protocol? That is, 
if this flag is set, we'd try to match only the part of the URL scheme up 
to the first + with this protocol name.

// Martin