

WebM and WebP Hand Ported to JavaScript for All Browsers - devongovett
http://badassjs.com/post/17218459521/webm-and-webp-hand-ported-to-javascript-for-all

======
jonny_eh
That is really awesome.

I wonder if the file size gains of switching to WebP is worth the hit of
including the WebP.js file. Of course you'd now require clients to support JS
but in this day and age that's reasonable anyways.

~~~
devongovett
I believe the point of WebP is that it is _smaller_ than JPEG and PNG files.
And the JS file is only 27 KB minified and gzipped...

~~~
InnocentB
Google claims an average-case 25-34% decrease in file sizes from JPEG and PNG,
so I guess if you have more than ~100K worth of images to serve it would be
worth your while, bandwidth-wise (though of course rendering time on the
client would go way up).

~~~
Someone
Rendering memory usage could change, too (most likely upwards). I haven't
looked at the source, but I guess this renders to canvas and keeps the
uncompressed data around in that canvas. Browsers might opt to uncompress
images on the fly when needed.

------
runn1ng
Do I understand it correctly that the whole codec runs in javascript?

------
fasteddie31003
I have mixed feelings about handling web media like this. It's probably very
well-done, interesting javascript, but I don't know if this is a long-term
solution for the web. I feel like high-performance decoding should be done in
the browser and is not Javascript's domain.

~~~
justincormack
But many people want to use free video formats on the web and Apple and
Microsoft are still refusing to ship them.

------
JoshTriplett
This seems like the right approach going forward, as long as JavaScript
engines continue to approach the performance of native code. This approach
keeps codec implementations in the JavaScript sandbox where they can't provide
new exploits, rather than extending the attack surface with large, frequently
exploited codecs.

In general, JavaScript seems like the right approach for anything that doesn't
require special privileges to do, and for that the APIs should focus on
creating the minimum possible interface that lets JavaScript do all the
interesting work.

~~~
modeless
I'd like to agree, but this makes a good benchmark, and right now it's showing
that JavaScript is about 20 times slower than native code on my machine in
both Chrome and Firefox. That's completely unacceptable for video decoding. In
fact, even if JavaScript was just as fast as native code it would still be
unacceptable for mobile video, where hardware acceleration is required for
acceptable performance and battery life.

~~~
devongovett
Just wait until browsers start supporting WebCL and we can do video decoding
on the graphics card :)

~~~
moonchrome
I'm betting WebCL running on CPU cores will beat JS by 20x margin as well.

------
est
How's WebP compared to ImageZero?

[https://kdepepo.wordpress.com/2012/01/30/fast-lossless-
color...](https://kdepepo.wordpress.com/2012/01/30/fast-lossless-color-image-
compression/)

~~~
ZeroGravitas
WebP is, by default, lossy whereas ImageZero is lossless so they're not
directly comparable. WebP does have an in-progress lossless mode though, known
as WebPll.

WebPll compresses better, but takes much longer to do it, therefore is better
suited to website images which are encoded once and transmitted multiple
times.

ImageZero compresses fast, but not as well, therefore is better suited to
saving images you are working on in a image editor to disk.

