You need Firefox nightly for it to run well, because it depends on the hybrid static/dynamic type inference work and some other optimizations. I believe that Brendan was demoing it from a Mac laptop of some kind.
As far as applications, it will let content providers who want to ship H.264 and pay the license fees do so without requiring all browser developers to pay such fees. (For Firefox it would be a meaningful portion of Mozilla's engineering budget.)
And it's a pretty compelling demo, IMO, of the fact that we're not done with JS performance yet, and that people don't need to be running to Dart or NaCl or other rip-and-replace technologies in order to get great perf. There's a lot of opportunity for even better performance on the engine side as well as the library side: they started a week ago with emscripten, Closure and the libstagefright C sources...
1. This works much faster on Firefox nightly (that's where we demo'd it on). Nightly has a lot of JS engine improvements that are not in stable yet (but will be in a month or two).
2. This does not use any hardware acceleration yet. This is simply compiling the Android C decoder into JS, nothing else - just a few days of work. We will now start to look at actually optimizing the code specifically for JS, and also to use GPU shaders for the relevant part of the code. Both of those can potentially make this even faster.
Regarding real-world applications, the interesting possibility is for websites to ship their own codecs. As I mentioned in a comment above, imagine an anime video website that ships a video decoder optimized for that kind of content - it could be much more efficient than stock H.264. Also, if websites can ship their own decoders, they can continually improve them (unlike now where websites rely on client decoders which are not constantly being improved).
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.
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.
As far as applications, it will let content providers who want to ship H.264 and pay the license fees do so without requiring all browser developers to pay such fees. (For Firefox it would be a meaningful portion of Mozilla's engineering budget.)
And it's a pretty compelling demo, IMO, of the fact that we're not done with JS performance yet, and that people don't need to be running to Dart or NaCl or other rip-and-replace technologies in order to get great perf. There's a lot of opportunity for even better performance on the engine side as well as the library side: they started a week ago with emscripten, Closure and the libstagefright C sources...