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

[Stephen Buck]

I have looked at Marc-André's python player that uses GStreamer for this protocol at http://gitorious.net/hls-player and it's great for understanding the protocol. I just need to turn this into a GStreamer plugin that plays well with playbin so that arbitrary players can make use of it.

It sounds like I should be a source since I can easily implement a URI property and use libsoup to do all of my HTTP work. This works well when the pipeline can be defined manually. Unfortunately, playbin uses souphttpsrc for all HTTP URIs. If I add an optional m3u8 sink pad and act like a decoder so that playbin will connect souphttpsrc to my source is there any way I could just ignore the incoming content but use its URI to initialize my URI? Definitely a hack, but it might give me compatibility with playbin.

On Jun 9, 2010, at 2:43 PM, Bastien Nocera wrote:

> 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
> 
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel