[FFmpeg-devel] [PATCH] Add Apple HTTP Live Streaming protocol handler

[Martin Storsjö]

Hi,

On Sun, 25 Jul 2010, Ronald S. Bultje wrote:

> On Sun, Jul 25, 2010 at 7:23 AM, Martin Storsj? <martin at martin.st> wrote:
> > Secondly, currently the implementation takes a full url to a playlist
> > after the applehttp:// part, such as
> > applehttp://http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8.
> > This allows using other underlying protocols, too, such as https:// (if
> > we'd ever implement that), or file:// for fetching the playlist locally -
> > mostly for testing. As another alternative, the urls could simply be
> > applehttp://devimages.apple.com/..., not allowing any other underlying
> > protocols than normal http, but making the urls look slightly less weird.
> 
> Why is this not a demuxer? It seems it's a playlist.

Yes, it's a playlist, but with some minor details - each segment is 
intended to follow straight on after the previous one, without resetting 
demuxers/decoders inbetween, etc. Also, for live streams, the playlist is 
a sliding window of current segments, so it has to reload the playlist 
regularly in those cases.

> Playlist support in FFmpeg might be near-nonexistant and require some
> significant extensions to the demuxer layer, but implementing it as a
> protocol does not sound quite right...

I thought about doing it as a demuxer, too, but implementing it that way 
would be way much more work, with setting up a chained demuxer and 
whatnot.

The content in these cases are MPEG-2 transport streams or MPEG-2 audio 
elementary streams - doing it this way, the protocol simply provides the 
demuxer with a byte stream formed by the files concatenated, which I feel 
is a quite proper abstraction here.

Protocol as name may feel incorrect, but as in the "opaque bytestream" as 
URLProtocols in libavformat actually are, I think the choice feels quite 
right.

// Martin