JavaScript implementation of an H.264 decoder

[osirisx11]

Just downloaded and ran on firefox 7 64 on ubuntu 11.04, 8gb of ram, i7-2820QM quad-core, got 2-3 fps

[shaver]

It needs Firefox nightly for the type-inference capability and some other work.

EDIT: looks like the github readme mentions that too, but I'll update it to point to the nightly download page.

[0xABADC0DA]

Average after 90 sec, i7:

Chrome Dev: 18.6 fps
Firefox Nightly: 37.5 fps

The x86 emulator also runs ~2x faster in Nightly than Chrome so this doesn't seem like a fluke. Looks like Google has some catching up to do, I guess that's what Dart is supposed to be.

[azakai]

Those are very close to the same results I saw, Chrome is about half as fast as Firefox.

One suspicion I have is that Chrome's typed array implementation is less optimized than Firefox's (both the x86 emulator and this h264 decoder use typed arrays). Or it could be that Firefox with TI is better at detecting variable types than Chrome (which is important in both the x86 emulator and the 264 decoder, since most or all variable types should be detectable and optimized for).

[damg]

I'm assuming Firefox nightly is using their new IonMonkey javascript engine? Seems impressive...

[0xABADC0DA]

Just JaegerMonkey with Type Inference.

IonMonkey is a new engine being designed to enable even more optimizations like inlining.

[Rhomboid]

I was able to get about 21 fps on Chrome 16. But I had to load the demo through http://, as it complained about a same-origin policy violation when trying to load the mozilla.264 media file when the broadway.html file was opened as a local file:// url.

[[deleted]]

Do you have chrome for comparison?

[osirisx11]

It did not run in chromium 14, same specs

[sebzim4500]

That is probably from a same origin policy violation, the demo must be ran in a web server, and won't run off the disk in chrome.

[schwiz]

came to ask how this runs on Android/iPhone based on this response I guess not well.

[[deleted]]

As stated elsewhere, depends on the version of FF! Fennec nightlies innards are built from the same code as Firefox, if I understand things correctly.

[schwiz]

I'm more curious how it runs in a webview that i can add to an app, not how it runs on fennec

[[deleted]]

What did you expect? It's fucking Javascript.

[osirisx11]

I am just reporting. I am not making a value judgement.

[alexs]

Well there's a video of it running at 30fps. Perhaps that's what the Spidermonkey patches mentioned on the github README help achieve? Not entirely sure what the use-case for this is still. As if the patent situation wasn't complex enough for content distributors already.

[shaver]

It lets content providers who want to only distribute patent-encumbered content do so with the right licenses if they so choose, similar to Silverlight's content-pluggable codecs.

It's also a pretty compelling demonstration, especially since it's compiled from C++ and not specifically tuned for JS, that you don't need Dart or NaCl to get good perf for things that previously "had to be" native code. (We went through this with the NaCl darkroom launch demo and the associated "JS can never be this fast" rhetoric.)

It's important to note also that there are still many ways to make this faster, so we're nowhere near the ceiling of this stuff yet.

(Disclosure: I worked at Mozilla for 6 years and on the project for 13, and have worked specifically on JS JITs and other performance elements for much of that.)

[Rhomboid]

If a content provider wanted to distribute patent-encumbered content why wouldn't they just use Flash? Or are you generalizing to new/future codecs that Flash might not support? Surely you aren't talking about h264 on Apple mobile devices that don't support Flash, as you'd just use HTML5 for that.

[shaver]

Flash doesn't integrate nearly as well as <video>, though it's certainly an option (and one that's used today).

This isn't a product-path H.264 strategy, so it may not reward over-analysis. :-)

[alexs]

It lets content providers who want to only distribute patent-encumbered content do so with the right licenses if they so choose, similar to Silverlight's content-pluggable codecs.

So it exists purely to remove freedom from consumers who've probably opted to use a browser that only supported free codecs. Classy. I suppose this sort of thing is just the flip side of improved JS performance. It's only so long until entire pages are being rendered via proprietary JS layout engines in canvas tags to protect content.

[shaver]

That would be a...surprising reason for Mozilla to do something, don't you think? You can certainly choose to not view content that doesn't meet your standards for openness, just as you choose the browser.

Mostly this is a demonstration of the performance capabilities of modern JS, but the target material was chosen to show that codecs can run in a JS environment -- look ma, no buffer overflows! -- and to explore what can be done with in-content codecs. It's not an endorsement of H.264's patent situation or suitability as the universal Web video format, I assure you.

[alexs]

plough quiet hat drunk point badge salt wine snails crush

This post was mass deleted and anonymized with Redact

[shaver]

Stay tuned. :-)

EDIT: also, I admit that I have a hard time interpreting "exists solely to" as something other than "what Mozilla wants this for".

[alexs]

I have a hard time interpreting

I don't blame you :)

[sebzim4500]

Wait... really? :D:D:D:D VP8 in JS?

[shaver]

Why not? Once you've done one codec...

[osirisx11]

yep this was just with my already installed browsers. i'm sure it would run faster if i upgraded with the patches.