HTTP Live Streaming demo: http://devimages.apple.com/iphone/samples/bipbopall.html

VLC can handle the .m3u8 playlist file but it starts and stops for each file segment which is useless. I'm stuck with Safari for now. I would love to see support for this and am willing to assist (but I don't have any Chromium experience). I've just built Chromium on FreeBSD so I'll start staring at the code.

I have done an http live streaming application using HTML5 player, how can i make it playing in chrome without flash fallback ?

With h.264 / mp4 being removed from Chrome is this even on the map anymore?  Other codecs could be used, but the main HLS providers today are using h.264.

Does honeycomb implement this in a way that Chromium can use?

As you state the only available clients (iOS, OS-X Quicktime) are using h.264 for the videoframes with HLS. The "protocol" however seems to be a fine solution for the given problem. Personally I'd love to see the adoption in Chrome because there is no solution for sliding window streaming without plugins today. (Flash, Silverlight, Real,...)

> the only available clients (iOS, OS-X Quicktime) 

This is incorrect. Android 3.0 Honeycomb introduced support for HTTP Live Streaming.

http://developer.android.com/sdk/android-3.0-highlights.html

Is there any explanation about why do you mark it as won't fix?
Thanks.

> Is there any explanation about why do you mark it as won't fix?

I'm looking for an answer as well. Like #10 said, there isn't any solution other ran resorting to ridiculously demanding plugins like Flash, or Silverlight.

I would love being able to deliver media through HLS using the webm container and the vp8 codec.

People subscribed to this bug may be interested in the issue I have just filed:

 Issue 109652 : Support MPEG-DASH

DASH support using the MediaSource API woud be great

Can the a chromium member or the one who marked this "WontFix" please give the reason for that resolution? Even if it is just due to specific plans to support something like  issue 109652  (though that didn't exist at the time wontfix was selected), please state something, people think this would be useful and it comes across as patronizing/insulting/dismissive to just give a no without any discussion.

http://code.google.com/p/chromium/issues/detail?id=109652#c2 provides the approach we're taking

it's very similar to why we don't support MP3 .m3u playlists: javascript can parse such a file and script an <audio> object w/o complicating the browser code

building on that concept, while HLS is more complicated that an MP3 playlist with something like the media source API you can accomplish the same end result using codecs, containers, and features of your choosing

As noted, HLS is more complicated than MP3 playlist and in fact it provides much more than just playlist support. There are already HTML5 media players with playlist support but they all fail to do GAPLESS playback of media files that is needed for (pseudo)streaming.

In-browser HLS support would allow to eliminate the time gap when switching between media files. I (and some other people) did some experiments with two interchangeable <video> elements and I wasn't able to achieve gapless playback.

By the way, Google TV (unlike stock Android) does support HLS
https://developers.google.com/tv/android/articles/hls

It's understandable that Google doesn't want to use certain proprietary technologies but currently MediaSource API have only experimental support and it's not even turned on by default in webkit. There is a big need in mechanisms that would support media streaming via HTML5!

Not sure if you've seen this already - http://dash-mse-test.appspot.com/
It seems to be the first signs of Chrome supporting a proper streaming protocol (mpeg-dash), although it's still in early stages at the moment.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.