[gst-devel] Implementing support for Apple HTTP Live Streaming...

[Michael Smith]

On Wed, Jun 9, 2010 at 10:30 AM, Stephen Buck <stephenbuck at mac.com> wrote:
> I'm currently implementing a GStreamer plugin to handle video playback using Apple's HTTP Live Streaming protocol (http://en.wikipedia.org/wiki/HTTP_Live_Streaming), which is used by the iPhone and iPad, and need some advice on the best way to proceed. The protocol works roughly like this:

Here's a rough outline of how I'd go about implementing this:

Implement an element called: applehttplivestreamingsrc.

This will be a bin, with a single source pad. Conceptually this is a
little similar to rtspsrc - that's a bin that has source pads (though
it has multiple source pads).

It'll have a property for the URI to the m3u file (and later other
things you might need to configure).

When it starts up, it'll fetch the m3u file. Probably best done by
internally instantiating an http uri handler element, and getting the
data from that - that way you don't tie it to souphttpsrc.

Then it can instantiate more http uri handlers, to get the actual
MPEGTS data. The first of these will be hooked up to the bin's src pad
(which is a ghost pad).

On receiving EOS on the http source, it'll switch out the http source
for the next source, and not let the EOS through. You may also need to
do some mangling of other events, like new segments? Can use event
probes for this, probably.

Later, you might add:
 - pre-fetching the next URI, and buffering (probably using a queue
element), so that at segment boundaries you don't stall while waiting
for the next connection to start up.
 - Re-fetching the m3u8 file when required for live streams.
 - Making your source bin implement the uri handler interface, with
some custom protocol, so you'd be able to do something like:
gst-launch playbin2 uri=applelivehttp://server/mystream.m3u8

Hope that helps a bit - though it doesn't directly answer your
questions, I think this design will work a lot better that what you
have currently.

Mike