Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP Live Streaming in JavaScript

blog.peer5.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: HTTP Live Streaming in JavaScript

#11

Post by praseodym »

sesm wrote: post #8

The problem with Apple HLS is that it uses MPEG TS container, which is not supported natively by the browsers (except Safari). So, any implementation of HLS in Chrome/Firefox should do the job of extracting video/audio from container using JavaScript (or Flash, like FlashHLS player does). A more standard-friendly solution is MPEG DASH, which is similar to HLS, but can use MP4 container supported natively by the brows…

The MPEG-TS container (from 1995!) is also a lot less efficient than the more modern MP4 container. Overhead can range from 5% to 30% with bad muxing settings.

See: * ​http://blog.zencoder.com/2011/12/08/announcing-the-clouds-mo... * ​http://features.encoding.com/blog/2014/02/24/simplify-http-l... * ​http://stackoverflow.com/questions/15661664/how-do-i-alter-m... * https://trac.ffmpeg.org/ticket/2857

Re: HTTP Live Streaming in JavaScript

#12

Post by biokoda »

sesm wrote: post #8

The problem with Apple HLS is that it uses MPEG TS container, which is not supported natively by the browsers (except Safari). So, any implementation of HLS in Chrome/Firefox should do the job of extracting video/audio from container using JavaScript (or Flash, like FlashHLS player does). A more standard-friendly solution is MPEG DASH, which is similar to HLS, but can use MP4 container supported natively by the brows…

> A more standard-friendly solution is MPEG DASH

Standard friendly yes. But not nearly as widely supported. Apple HLS runs on adroid, iOS, a large number of set-top-boxes, flash and now javascript.

Re: HTTP Live Streaming in JavaScript

#13

Post by mentando »

voltagex_ wrote: post #6
jaitsu wrote: post #2

Great article. I think we can actually talk about flash being replaced now that we have a real solution for HTML5 live streaming. Flash was never going to go away until there was something that could handle the DRM across all browsers. I've worked a lot with Ooyala's live streams and was just looking at moving a client over to their HTML5 offering. They claim to offer it in all browsers but that is probably with a fl…

>All tests were done on Intel Corei7-4810MQ machine. I think we'd have to see 60fps on a Chromebook or similar low-cost machine before we declared the end of Flash streaming.

Yeah. My Chromebook cannot handle 720p60 on Youtube, but it is a rather low power one with its Celeron N2840.

Re: HTTP Live Streaming in JavaScript

#14

Post by madeofpalk »

praseodym wrote: post #10

A better solution would be to deploy a media server that can provide multiple stream formats. For example, Microsoft IIS Media Services [1] supports Microsoft's Smooth Streaming, HLS and MPEG-DASH without having to re-encode video for each format. With such a solution, nearly every client out there can use a natively supported stream format without overhead. Also, Microsoft has a decent cloud offering with Windows Az…

I think at the end of the day the better solution for most people would be to use something like Brightcove, The Platform, Ooyala, Adobe, paid Vimeo, or even Youtube.

Unless you're Netflix, I wouldn't bother with this stuff yourself. Even then, a lot of (A)VOD sites 'outsource' this stuff to Brightcove or The Platform.

Re: HTTP Live Streaming in JavaScript

#15

Post by clouddrover »

sesm wrote: post #8

The problem with Apple HLS is that it uses MPEG TS container, which is not supported natively by the browsers (except Safari). So, any implementation of HLS in Chrome/Firefox should do the job of extracting video/audio from container using JavaScript (or Flash, like FlashHLS player does). A more standard-friendly solution is MPEG DASH, which is similar to HLS, but can use MP4 container supported natively by the brows…

But a problem with DASH is that the MPEG LA is attempting to form a patent pool, presumably with the goal of charging a patent license fee. The MPEG LA's Larry Horn says, "Market adoption of DASH technology standards has increased to the point where the market would benefit from the availability of a convenient nondiscriminatory, nonexclusive worldwide one-stop patent pool license".

I think this means the future of DASH is not user friendly: http://www.mpegla.com/main/pid/MPEG-DASH/default.aspx

Re: HTTP Live Streaming in JavaScript

#16

Post by alexduros »

jaitsu wrote: post #2

Great article. I think we can actually talk about flash being replaced now that we have a real solution for HTML5 live streaming. Flash was never going to go away until there was something that could handle the DRM across all browsers. I've worked a lot with Ooyala's live streams and was just looking at moving a client over to their HTML5 offering. They claim to offer it in all browsers but that is probably with a fl…

> Obviously DRM would still be an issue unless the browser natively supports EME.

Actually, with HLS, DRM is an issue on browsers since HLS is not designed to work with EME spec.

By the way, some open source players like https://github.com/canalplus/rx-player implements EME spec to work with DRM, Smooth Streaming Format or MPEG DASH format, that are compatible with the common encryption model.

Re: HTTP Live Streaming in JavaScript

#18

Post by dmm »

Has anyone implemented HLS or DASH in an application that required low-latency? How low were you able to get it?

With DASH I have been able to achieve 5s by using small chunks and a short interval between iframes.

Re: HTTP Live Streaming in JavaScript

#20

Post by sethd »

sesm wrote: post #8

The problem with Apple HLS is that it uses MPEG TS container, which is not supported natively by the browsers (except Safari). So, any implementation of HLS in Chrome/Firefox should do the job of extracting video/audio from container using JavaScript (or Flash, like FlashHLS player does). A more standard-friendly solution is MPEG DASH, which is similar to HLS, but can use MP4 container supported natively by the brows…

Another reason HLS is so widely used is that the App Store Guidelines require it for video streaming longer than 10 minutes:

Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps or lower HTTP Live stream

It's also the only format that works with Apple TV via AirPlay.

If you're already deploying HLS to target iOS and Apple TV (natively as well as in Safari), and HLS is already supported in other devices like Android, desktop browsers via Flash, and now JavaScript, then it seems like the path of least resistance.

Post reply on HN