[FFmpeg-devel] [PATCH] Add Apple HTTP Live Streaming protocol handler
Sun Jul 25 20:35:14 CEST 2010
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
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
More information about the ffmpeg-devel