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

[Martin Storsjö]

On Mon, 28 Feb 2011, Martin Storsj? wrote:

> On Mon, 28 Feb 2011, Luca Barbato wrote:
> 
> > On 02/28/2011 12:54 PM, Martin Storsj? wrote:
> > > 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.
> > 
> > might be useful go to this route and change the url splitter accordingly
> > in the long run.
> 
> I'm not sure the url splitter in itself should be changed - there's no 
> inherent meaning in using + as a separator. I'll try to prototype the 
> thing I suggested above, though.

Implemented this in the attached patches. Do you think this looks like a 
sensible approach?

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-URLProtocol-Add-a-flags-field.patch
Type: text/x-diff
Size: 698 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110228/487c53cf/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-URLProtocol-Add-URL_PROTOCOL_FLAG_NESTED_SCHEME.patch
Type: text/x-diff
Size: 2351 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110228/487c53cf/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Add-Apple-HTTP-Live-Streaming-protocol-handler.patch
Type: text/x-diff
Size: 13489 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110228/487c53cf/attachment-0002.patch>