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

A JavaScript H.264 decoder

github.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: A JavaScript H.264 decoder

#31

Post by wmf »

sp332 wrote: post #21
gerggerg wrote: post #14

Any one know what the legal implications of using a free decoder for a patented compression format are? Products like flash make it seem free as Adobe pays a flat rate to the patent holders for decoding mp3, h.264, etc. alleviating their users from having to worry about royalties. But would using this decoder, though free and open source, be infringing a patent? note: I realize it's not production code. I'm asking mo…

At least until 2015, you won't need a license unless you're distributing commercial content to other end users or building an H.264 encoder. And the MPEG-LA has agreed to never charge anyone for watching free videos, so Youtube viewers will never get shaken down. http://www.engadget.com/2010/05/04/know-your-rights-h-264-pa... Maybe after 2015, they will start collecting royalties on commercial decoders.

It sure looks like decoders have to pay: http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsS...

Re: A JavaScript H.264 decoder

#32

Post by yuhong »

DarkShikari wrote: post #18
shaver wrote: post #15

Earlier quoted context omitted.

Use and distribution of implementations requires a license (though, curiously, x264 seems to get a pass), so using the decoder will require a license as with using a closed-source one.

(though, curiously, x264 seems to get a pass) If x264 does, so does VLC, mplayer, ffmpeg, gstreamer, and dozens of other applications that use video and audio decoders in Linux. Fortunately quite a lot of the world is not the United States, and today VLC is the world's second most popular media player and has never paid one cent in patent licensing fees. But of course, yes, being open source does not magically exempt…

Hopefully MPEG LA is seeing this and will sort out licensing for websites using this.

Re: A JavaScript H.264 decoder

#34

Post by watmough »

pcwalton wrote: post #19
shaver wrote: post #12

Earlier quoted context omitted.

Brendan's demo was running at 30fps, I believe on a Macbook Pro (I'll find out). Some content will run slower right now, which is true of all codecs AFAIK but is more so for this stuff right now. The patches linked from the github README aren't necessary to run the transpiled version that was in the demo -- it's a memory optimization that's being used in the tuned-for-JS version. As regards derpiness: it lets content…

It was on a MacBook Pro. We tried it on a MacBook Air too and it performed reasonably well.

My 2007 MBP manages a decent 20 fps but starts pretty slow and averages 15.

That's a 2.4GHz C2D. Need to try it on my i52400.

Re: A JavaScript H.264 decoder

#35

Post by InclinedPlane »

__alexs wrote: post #7

Apparently this can actually get decent frame rates. Although I suspect they are using the patched version of the JS interpreter mentioned on github. http://yfrog.com/nmng0z Still not sure how this is meant to actually be useful though. The problem with H.264 isn't availability of implementations, it's being non-free and heavily patented. I can kind of see a use for this if you are a big content provider with a bunch…

It's a proof of the power of javascript. In another 10 years it'll be even faster due to faster compilers and faster processors.

Perhaps by then it'll be completely routine for video to be encoded and decoded using Javascript on a mobile device.

Re: A JavaScript H.264 decoder

#36

Post by klodolph »

azakai wrote: post #22
__alexs wrote: post #7

Apparently this can actually get decent frame rates. Although I suspect they are using the patched version of the JS interpreter mentioned on github. http://yfrog.com/nmng0z Still not sure how this is meant to actually be useful though. The problem with H.264 isn't availability of implementations, it's being non-free and heavily patented. I can kind of see a use for this if you are a big content provider with a bunch…

> Although I suspect they are using the patched version of the JS interpreter mentioned on github. We are using standard Firefox, no special patches. However, we used the Firefox nightly, not current stable. The decoder runs much faster in nightly, due to JS engine improvements that landed over the last few months, and are not yet in stable. > Still not sure how this is meant to actually be useful though. The problem…

> if we get this codec to run as fast as a native one

Native ones have chunks written in hand-tuned assembly language, offload parts to specialized hardware, and other such tricks not available to ECMAScript. I'm not even sure why "as fast" is being considered a possibility.

Re: A JavaScript H.264 decoder

#37

Post by mbebenita »

klodolph wrote: post #36
azakai wrote: post #22

Earlier quoted context omitted.

> Although I suspect they are using the patched version of the JS interpreter mentioned on github. We are using standard Firefox, no special patches. However, we used the Firefox nightly, not current stable. The decoder runs much faster in nightly, due to JS engine improvements that landed over the last few months, and are not yet in stable. > Still not sure how this is meant to actually be useful though. The problem…

> if we get this codec to run as fast as a native one Native ones have chunks written in hand-tuned assembly language, offload parts to specialized hardware, and other such tricks not available to ECMAScript. I'm not even sure why "as fast" is being considered a possibility.

Well, for instance, we can take advantage of hardware features like shaders in WebGL or make use of WebCL, rivertrail, etc., which are all available to JavaScript. Perhaps we may not reach the performance of native codecs, but we can get close enough.

Re: A JavaScript H.264 decoder

#38

Post by mbebenita »

watmough wrote: post #34
pcwalton wrote: post #19

Earlier quoted context omitted.

It was on a MacBook Pro. We tried it on a MacBook Air too and it performed reasonably well.

My 2007 MBP manages a decent 20 fps but starts pretty slow and averages 15. That's a 2.4GHz C2D. Need to try it on my i52400.

You should give the latest version a try, we improved the performance considerably.

Re: A JavaScript H.264 decoder

#40

Post by azakai »

klodolph wrote: post #36
azakai wrote: post #22

Earlier quoted context omitted.

> Although I suspect they are using the patched version of the JS interpreter mentioned on github. We are using standard Firefox, no special patches. However, we used the Firefox nightly, not current stable. The decoder runs much faster in nightly, due to JS engine improvements that landed over the last few months, and are not yet in stable. > Still not sure how this is meant to actually be useful though. The problem…

> if we get this codec to run as fast as a native one Native ones have chunks written in hand-tuned assembly language, offload parts to specialized hardware, and other such tricks not available to ECMAScript. I'm not even sure why "as fast" is being considered a possibility.

I agree in general that native decoders can be faster - they can in principle do anything a JS decoder can, and in addition the things you mention. However,

1. JS can also use hardware acceleration through WebGL. We have not done this yet, but will. 2. JS has some proposed extensions, WebCL and Intel's RiverTrail, which let it utilize SIMD and other computing hardware. We will investigate using those too.

With those two things, we believe JS performance will be very good. How close it will be to native code, though, is hard to say at this point in time.

However, there is one big advantage a JS decoder would have, that native code does not: A JS decoder can be downloaded and run securely. As a consequence, you can continually improve your decoder in JS and your users will run the latest, most optimized version, while standard native decoders are typically upgraded much, much less frequently. Also worth noting is the potential to ship specialized decoders, as I mentioned in another comment, imagine an anime website that ships a video decoder heavily optimized for that specific type of content. That could be much more efficient than a stock native decoder.

Finally, it's worth noting that the decoder we compiled from C, Android's H.264 decoder, does not have any substantial amount of handwritten assembly. I had assumed like you said, that real-world decoders would have such things, and am curious why it doesn't. If anyone reading knows the answer I'd be very interested in that.

Post reply on HN