MPEG1 Video Decoder in JavaScript(phoboslab.org)
phoboslab.org
MPEG1 Video Decoder in JavaScript
http://phoboslab.org/log/2013/05/mpeg1-video-decoder-in-javascript
12 comments
I have to say that, while I haven't looked into the details, this is quite impressive. It runs really smooth on my not-so-great desktop. A good sign that Javascript is no longer the great bottleneck it used to be.
Decoding is pretty fast - which surprised me as well.
The main performance hog is not the decoding, but the conversion of the decoded YUV image to RGB for the canvas element. I believe this step could also be done on the GPU with WebGL.
The main performance hog is not the decoding, but the conversion of the decoded YUV image to RGB for the canvas element. I believe this step could also be done on the GPU with WebGL.
I want to say you could use a higher end Pentium for software MPEG decoding (166-200MHz). Whatever the performance difference is between than and your current system (or the current minimum system you'd need to run that demo at full speed).
While I think the code is cool, why we can do this is just because we have waited 20 years. A MPEG1 decoder can run in software on a reasonable ARM9 core from 15 years ago, and desktop processors from 20 years ago can probably do it as well.
MPEG1 decoding isn't particularly difficult, computationally speaking.
Yet another indicator of how powerful modern CPUs and modern javascript has become. Yet when I see projects like this, I think about how everyone's video cards & chips already have hardware video decoding. Why are we not given access to those APIs? This seems fundamental, yet never a peep about them. I want access to my own friggen hardware. And it's about time video decoding got standardized, isn't it? Why, other than media publishers being afraid of it, do we not have access to these APIs?
You certainly do have access to those APIs. You can use DirectShow on windows, libva on linux, OpenMAX on android, whatever Apple picked on iOS, etc... But be careful to probe correctly, because not all backends support all the features the same way. And not all hardware supports all profiles the same way. But it's certainly not a problem of "access".
I know what you're really thinking is a little pushbutton Javascript API where you can hand it an url and say "play". The real world doesn't work like that, sadly. Media handling is wildly complicated, and I didn't even need to invoke DRM here.
I know what you're really thinking is a little pushbutton Javascript API where you can hand it an url and say "play". The real world doesn't work like that, sadly. Media handling is wildly complicated, and I didn't even need to invoke DRM here.
This has been discussed extensively. Different systems have different codecs installed, so having the browser pass through to OS/hardware codecs leads to non-interoperability (the same problem as with EME). Also, Mozilla and Google were trying for a while to strong-arm the world into adopting VP8 by denying access to other codecs, but that didn't pan out.
MP3 would be standard codec for audio if the only concern was interoperability. It was officially motivated by non-encouraging of usage of patented formats.
We do, in some sense. The <video> tag is hardware accelerated on many platforms. It's not a direct "decode this frame using the hardware" API, but if you're trying to serve up a video, it does the job. Is there something specific you're looking to do with a lower-level API?
This is really cool. It seems to me that what browsers really need in order to unlock huge amount of potential in high performance graphics is an API for hardware accelerated DSP operations like FFT.
Do you means something like WebCL[1]? It's not stardized, and caniuse.com hasn't even heard of it, but it's definitely on the horizon. Wikipedia[2] says there are already some implementations.
[1] - http://www.khronos.org/webcl/
[2] - http://en.wikipedia.org/wiki/WebCL
[1] - http://www.khronos.org/webcl/
[2] - http://en.wikipedia.org/wiki/WebCL