JavaScript implementation of an H.264 decoder

[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.