The same could be said about CPAN and NPM. Yet Perl is basically dead and JavaScript isn't used for any machine learning tasks as far as I'm aware. WebAssembly did help bring a niche array of audio and video codecs to the ecosystem[1][2], something I'm yet to see from Python.
I don't use Python, but with what little exposure I've had to it at work, its overall sluggish performance and need to set up a dozen virtualenvs -- only to dockerize everything in cursed ways when deploying -- makes me wonder how or why people bother with it at all beyond some 5-line script. Then again, Perl used to be THE glue language in the past and mod_perl was as big as FastAPI, and Perl users would also point out how CPAN was unparalleled in breadth and depth. I wonder if Python will follow a similar fate as Perl. One can hope :-)
[1] https://github.com/phoboslab/Ejecta
[2] https://github.com/phoboslab/jsmpeg
[3] http://phoboslab.org/#games
[4] http://zty.pe/
It is unlikely to ever compete battery-wise with hardware support for a codec, however.
Of course it has some drawbacks, as MPEG1 is a pretty old codec. The data rate is fairly high and it struggles with high resolution streams. 720p still decodes nicely in realtime on most mobile devices, though.
I can't use WebRTC yet because I want to have support for IE and especially Safari & Mobile Safari. I want to add audio for an iOS App[1] that's using jsmpeg[2] for video streaming.
The "video" quality is pretty bad though. From what I can see, the app streams base64 encoded JPEGs via WebSockets and draws them in a Canvas. The overhead of sending complete images costs a lot of bandwidth.
You may want to look into jsmpeg for live streaming: https://github.com/phoboslab/jsmpeg
> This completely disregards anything motion estimation
A good xng encoder could work around this by doing the motion estimation and encoding transparent regions where things don't change on subsequent frames which could reduce file size dramatically.
There's no question that for longer video clips, a native format like mpeg4 will outperform, especially on mobile. This XNG thing does play smoothly on my iPhone 5s with iOS 8 however.
> Using canvas with JavaScript to render something akin to simple MPEG
This has been done and jsmpeg is one such implementation - https://github.com/phoboslab/jsmpeg
Live demo here: http://stream.imdeity.com [ The macro blocks/visual glitches in that demo are a result of the live capture/encoding via ffmpeg and not a jsmpeg problem ]
The downside with the jsmpeg approach is that it requires accompanying Javascript to work and won't animate as a standalone file unlike this XNG method.
> 60% CPU usage and a memory leak pushing my Chrome past a GB and that's just the start of it.
Seeing high memory use on my Chrome as well but only 8% CPU usage with the multiple XNGs on that page playing at the same time (which is about the same as a single Flash-based Youtube video playing in another tab).
Again, definitely not production ready but has high potential when paired with a good encoder.
https://github.com/phoboslab/jsmpeg
example:
http://phoboslab.org/log/2013/05/mpeg1-video-decoder-in-java...
MPEG1 in javascript is pretty fast and runs at native speeds on phones
https://github.com/phoboslab/jsmpeg
but MPEG4/H.264 is not
If this could encode an MPEG in realtime (it should be fast enough on Desktop PCs and browsers with asm.js support, right?), you could send WebCam video via WebSockets to a server, distribute it and decode again with jsmpeg[1]. Sort of like the ghetto version of WebRTC, but without all the codec hassles :)
The framerate is quite low at the moment, but that's probably because of HN?!
Edit: it also sends full JPEGs of the screen when there's much going on. I believe my JSMPEG[1] would really be a viable alternative for this use-case. Streaming support is in the works :)