[shaver]

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.

[pcwalton]

It was on a MacBook Pro. We tried it on a MacBook Air too and it performed reasonably well.

[watmough]

My 2007 MBP manages a decent 20 fps but starts pretty slow and averages 15.

That's a 2.4GHz C2D. Need to try it on my i52400.

[mbebenita]

You should give the latest version a try, we improved the performance considerably.

[watmough]

Interestingly, my i52400 only manages 25 fps (average over 1 minute). Hmmm. Ahhh, it's only single-threaded.

Is that intentional, or a problem with Nightly?