
A JavaScript H.264 decoder - tnajdek
https://github.com/mbebenita/Broadway
======
__alexs
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 of cash and want to distribute video to Firefox users without
transcoding but it still seems pretty derpy.

~~~
azakai
> 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
> with H.264 isn't availability of implementations, it's being non-free and
> heavily patented.

First thing, this at least gives you another option. That is, if we get this
codec to run as fast as a native one, then we now have the choice of either
the browser __or __the video website providing the decoder (and properly
licensing the decoder, if they are in a country that has pure software
patents). More options are never a bad thing.

But I think the real potential in this approach is something entirely
different. The opportunity is that __you can download arbitrary decoders __.
So instead of the current world we live in, where you have a few decoders
installed, you can have custom ones for different websites. Imagine a website
that has cartoon videos or anime etc. - in principle, they could use a custom
codec that is heavily optimized for that kind of content, as opposed to being
forced to use stock decoders.

Also, it prevents being frozen in time: If you can download decoders from the
web, you can improve them constantly while making sure your users have the
proper decoder (since you ship it to them yourself), which you can't do if you
rely on stock preinstalled decoders.

~~~
klodolph
> 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.

~~~
azakai
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.

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

~~~
shaver
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.

~~~
DarkShikari
_(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.

~~~
shaver
You're right, of course. While I believe that the MPEG-LA's enforcement
practices are _not_ non-discrimatory as it's claimed to be, that's a different
discussion, and it wasn't appropriate to single x264 out that way.

I apologize.

------
hmottestad
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?

~~~
ck2
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.

~~~
robert-boehnke
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 :)

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

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

------
devongovett
Here's the BadassJS perspective on all of this very impressive stuff!
[http://badassjs.com/post/12035631618/broadway-
an-h-264-decod...](http://badassjs.com/post/12035631618/broadway-
an-h-264-decoder-in-javascript-running-at)

------
andhow
Wow. 45 fps in a Firefox nightly, 20 fps in Chromium. Pretty impressive for
JS.

~~~
mbebenita
Give it another try. We made a few small improvements that turned out to be
quite significant.

------
hackermom
Funny hobby project.

~~~
BrendanEich
... said the dinosaur to the first mammal, re: size, fur, and all that hobby
fluff.

~~~
hackermom
You just can't compare a JS library for h.264 decoding with ditto made in C.
The latter is usable while the former is practically useless even for an
extreme case of f.e. online, browser-based video editing. What is the point
you are trying to make?

