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

[Bastien Nocera]

On Wed, 2010-06-09 at 11:53 -0700, Michael Smith wrote:
> 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.

That shouldn't be needed.

>  - 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

Gross. It already has a specific mime-type, and should be pretty easy to
add a typefinder for (check shared-mime-info for some details).

> 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.

I'll just add that Marc-André was looking at implementing this on IRC as
well.

Cheers