Live data from Hacker News

A JavaScript H.264 decoder

github.com

11–20 of 43 posts

Re: A JavaScript H.264 decoder

#11

Earlier quoted context omitted.

hmmm.... What browser, OS and what Pentium 4 processor? And for how long did you run the video? Mine drops to 1.7 after a few seconds, the first few frames are dark so in the beginning I get 6 fps.

Nightly, XP, 2.4 Ghz. Nearly 5 Minutes.. Here it starts at like 0.6 fps, and then runs at 4-7 fps onwards.

Must be something with Nightly then, I'm just running the regular version.

Says a lot about the importance of software over hardware :)

Re: A JavaScript H.264 decoder

#12
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…

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 distributors decide to pay for H.264, if they want, exactly, and paves the way for other codecs to be deployed by such distributors as well. It also runs the codec in a managed environment -- format decoders are often very fertile territory for exploitable bugs, since they are pretty much by definition all about pointer math and byte-poking. But the initial intent, when they decided a week ago to try it, was to push the envelope of JS performance such that we find new ways to extend said envelope.

Re: A JavaScript H.264 decoder

#13

Running on a macbook pro with i5 dual core 2.4 ghz, it uses 1 core at 100% in firefox and manages: 1.7 fps It's cool, but I don't see any real world applications. Anyone got any ideas?

With today's Nightly I'm getting ~20fps on a 3.4 GHz Core i7 iMac but with drops into the 7fps range on some video transitions. Surprisingly, I get roughly the same perf with a current Aurora as well but the drops only go down to ~12fps. Trying it on the released Firefox gets around 2fps.

Re: A JavaScript H.264 decoder

#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 more about the concept.

Re: A JavaScript H.264 decoder

#15

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…

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.

Re: A JavaScript H.264 decoder

#16

Earlier quoted context omitted.

Nightly, XP, 2.4 Ghz. Nearly 5 Minutes.. Here it starts at like 0.6 fps, and then runs at 4-7 fps onwards.

Must be something with Nightly then, I'm just running the regular version. Says a lot about the importance of software over hardware :)

It definitely needs nightly. I'm not sure what's up with salmanapk's setup, will need to dig into it.

Re: A JavaScript H.264 decoder

#17
post #3

Earlier quoted context omitted.

I think it's more of an (impressive) mental exercise - if the code can be made straightforward enough to run on javascript, the future applications can only grow from there.

It's the Android encoder written in c++ cross compiled to JavaScript, not much of a mental exercise. Not to say it's not cool :)

They have a hand-coded javascript version in progress too:

https://github.com/mbebenita/Broadway/tree/master/Play

Re: A JavaScript H.264 decoder

#18
post #15

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…

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 you from patent laws in countries with insane, broken patent laws. In practice, if you want to make a large-scale commercial application that will be distributed in the US that uses x264, you will probably need to pay for an MPEG-LA license. They're quite cheap, though: 0 cents per unit up to 100k units, 20 cents per unit after that until 5 million, and 10 cents per unit after that.

Largely, the question of whether a distro contains any particular piece of software is whether the people who run the repositories are willing to host it. This applies both to possibly-patented software, but also to libraries like DeCSS (necessary to play DVDs) that violate the laws in some countries, but not others.

Re: A JavaScript H.264 decoder

#19
post #12
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…

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.
Post reply on HN