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

Ronald S. Bultje rsbultje
Mon Jul 26 17:41:03 CEST 2010

Hi Martin,

On Mon, Jul 26, 2010 at 11:36 AM, Martin Storsj? <martin at martin.st> wrote:
> 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.

So, my impression is that these playlists list "uri" + "bitrate",
maybe some more (can you cp a sample playlist so we can assess?).

What if I want to backup all of them? For example, so I can restream
it with bitrate selection from my own server later on. With RTSP (e.g.
RDT/Realmedia), this is possible in FFmpeg (though not in Xine,
Mplayer or any of the others). It's tested and works. That wouldn't
work in your setup, unless you implement it as a


More information about the ffmpeg-devel mailing list