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

Martin Storsjö martin
Mon Jul 26 17:36:37 CEST 2010


On Mon, 26 Jul 2010, Ronald S. Bultje wrote:

> On Sun, Jul 25, 2010 at 2:35 PM, Martin Storsj? <martin at martin.st> wrote:
> > 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.
> [..]
> > 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.
> 
> I think that's only true for as long as FFmpeg has virtually no
> playlist support.
> 
> Imagine a situation where playlist support (implemented as discussed
> in the past) is 100% functional in FFmpeg. Would you now still
> implement this particular playlist as a protocol?

Yes, I think I would. The number of differences compared to normal, 
generic playlists is still larger than the similarities, when it comes to 
implementation detail.

// Martin



More information about the ffmpeg-devel mailing list