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

[Martin Storsjö]

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

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

It's quite a bit more than that.

There are two kinds of playlists in this setup, variant playlists and 
normal segment playlists. A variant playlist points to one or more segment 
playlists, specifying their bitrate. It looks like this:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
gear1/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=311111
gear2/prog_index.m3u8

At this level, you most definitely don't want to play this as a normal 
playlist, since you should just play one of them.

The normal segment playlists, e.g. gear1/prog_index.m3u8 in this case, 
looks like this:

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10, no desc
fileSequence0.ts
#EXTINF:10, no desc
fileSequence1.ts
#EXTINF:10, no desc
fileSequence2.ts
...
#EXT-X-ENDLIST

This points to many mpegts segment files that should be played back to 
back without resetting the decoder inbetween.

Every bitrate variant should be segmented into similar segments, so if you 
want to switch to another bitrate variant, you just start reading from the 
corresponding segment in that variant instead.

For live streams, you don't have the "#EXT-X-ENDLIST" tag at the end, to 
indicate that there are more segments, and you should poll the playlist 
with the interval specified in #EXT-X-TARGETDURATION. For live streams, 
you may not always want to keep all the old segments available, so then 
you can drop files off from the start of the playlist and increment the 
#EXT-X-MEDIA-SEQUENCE counter, to indicate where in the stream the 
playlist starts.

It could e.g. look like this:

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:42
#EXTINF:10, no desc
fileSequence42.ts
#EXTINF:10, no desc
fileSequence43.ts
#EXTINF:10, no desc
fileSequence44.ts


> What if I want to backup all of them?

Then wget (or something similar) may be the best choice, I'd say...

> 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 demuxer-with-chains...

Umm, you can have multiple bitrates in RTSP? Do you receive them all at 
the same time if you want to backup them, as you say?

And how would that work for this setup? Do you mean that all the parallel 
streams should be available in the demuxer, so that I'd have high bitrate 
video in stream 0, high bitrate audio in stream 1, low bitrate video in 
stream 2 and low bitrate audio in stream 3? While it could be useful in 
some cases, I don't see that as a necessity. If you really want to get all 
of them, grab one bitrate per session, with many invocations in parallel.

If you want to restream it in the same format, wget (or something similar 
that handles .m3u8) is simply the easiest way - you get the content 
exactly as it was on the server, just copy to a folder on your server and 
you're done. If you pull it through ffmpeg, you'd lose all the segmenting, 
which you'd have to redo in one way or another, even if you'd have it all 
in a demuxer.

// Martin