Or you could think of it as taking a compute-intensive problem and distributing it widely.

Or taking a bandwidth-bound problem and completely eliminating that bottleneck.

If you've got 1000 people converting videos at once, the embarrassingly parallel isn't going to help you much on the server.

This does look like fun, and really a nice validation for emscripten, and there's a ton of practical application.

Computation intensive applications can be done in multithread by easily using web workers. It is been around for a long time. See the following site for a quick benchmark. [1]

[1]: http://pmav.eu/stuff/javascript-webworkers/

Here are my results: 8 Workers, Test: 2^1024000000 mod 97777 = 20631, 1515 ms 4 Workers, Test: 2^1024000000 mod 97777 = 20631, 2899 ms 2 Workers, Test: 2^1024000000 mod 97777 = 20631, 5773 ms 1 Worker, Test: 2^1024000000 mod 97777 = 20631, 11508 ms

Video encoding/decoding are in fact not embarassingly parallel. Lots of modern codecs have complex interdependencies between frames and sections of frames that make it harder to do things in parallel, as I understand it.

:) well, technically they did use a web worker in their demo, so it's on a background thread, at least.

So you're saying that people should never do anything unless it has an immediate useful result?

If you combine fixed-point arithmetics, tiled memory access patterns, asm.js, and dynamic image processing pipeline compilation (the way that, for example, VirtualDub did it), you'll probably discover that the "slow single-threaded language" probably isn't slow at all for image processing tasks. (And WebCL is still on the horizon.)