Hacker News new | comments | show | ask | jobs | submit login
Route9.js: A VP8/WebM decoder in JavaScript (badassjs.com)
46 points by devongovett on Nov 30, 2011 | hide | past | web | favorite | 13 comments

Neat, but it runs best on Chrome, which already has VP8/WebM.

I'm hoping eventually all the browsers will have something low level and fast enough to realistically do this kind of thing (e.x. Native Client)

A lot of things that need native speeds can be run in sandboxes with a few IO APIs (network, display, user input) just fine. Video codecs are a perfect example.

Imagine being able to link your app to the best available version of HTML6 immediately... or some other application development environment entirely.

> I'm hoping eventually all the browsers will have something low level and fast enough to realistically do this kind of thing (e.x. Native Client)

I don't think Native Client is the solution. For technical reasons, the sandboxing mechanism there has a big cost to entering and leaving the sandbox. The worst case for that is something like a codec, where you constantly stream information in and out. NaCl works better when you have lots of computation and very little input/output.

(That might be fixable in theory, but just as fixable is the speed of JavaScript.)

The cost is per transition and transferring a single native array per frame should be cheap. There is no reason a NaCl decoder couldn't limit itself to one write per frame and a single read when more data comes in.

One write per frame would potentially be not so bad, that's true. I wonder though if you don't need to do some security measures there that could end up as significant overhead (for example, JS engines have some anti-heapspray techniques that do things to typed arrays - transferring large arrays between the NaCl sandbox and the JS sandbox might want similar things). But maybe not.

Regardless, I think there are more suitable technologies for codecs on the web: A lot can be done in WebGL shaders (Broadway is starting to work on that), and proposed web standards like WebCL and RiverTrail look promising too.

To be honest I haven't looked at NaCl closely, I was just giving an example of the kind of thing I'm talking about.

Is there any way to make network requests and draw to the screen from within the sandbox, or does all IO need to be done in JavaScript?

Lets get real here: Native Client is never going to make it into all browsers, especially mobile ones. The point of this demo is to show that JS is fast enough for our needs and we don't need things like NaCl to get good performance. Yes it runs best in Chrome now, but I have a feeling that other browsers will catch up soon. In fact, it might even run well in Safari now but unfortunately Safari doesn't support Float32Array and there is no shim... Anyway, worth testing.

The good news from yesterday was that IE10 will have typed arrays. I assume that Safari will enable them by default soon - so all modern browsers will soon support typed arrays, and should run code like this very well.

Right now this demo is faster in Chrome it seems, while the original Broadway (H264 instead of WebM) is faster in Firefox, but the important thing is that the differences are not that big, and all JS engines are in very good shape and improving. We'll have even better performance a year from now.

Actually, Safari already enables typed arrays by default (separately from the rest of WebGL), but the latest stable version doesn't support Float64Array. The demo works fine on the WebKit nightly, although with considerably less FPS than either Firefox or Chrome.

Good to know, thanks for the info! Hopefully Float64Array will be added soon.

I'm surprised it is much slower than Firefox and Chrome, though. Apple recently enabled the new JSC JIT on all platforms, I thought, which should be quite fast. Maybe typed arrays have not been specifically optimized yet or something like that.

"Fast enough" pegs my CPU usage at 100%.

Solutions to that are coming as well. We see parallel processing abilities for JS starting to take shape like Intel's RiverTrail project, and initiatives like WebCL to bring the power of the GPU to the browser as well.

In the case of video codecs, while software decoders are certainly easily sandboxed[1], my laptop's H.264 hardware decoder is far, far better at not cooking my lap.

I'd love to see WebKit inside NaCl, though.

[1] with the caveat that NaCl is not the best way to sandbox them, since video codecs often include hand-coded assembly for maximum performance, which can be run just fine inside an OS sandbox, but doesn't play well with the custom code demanded by NaCl's software fault isolation. To some extent, I don't understand why NaCl exists, as its advantages over such an sandbox are minimal, but that's a rant for another day.

You laptop has a _hardware_ H.264 decoder? What laptop is that? GPU shader code != hardware.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact