The "Why Use JSMPEG" section hits the nail on the head with respect to the needs of some projects I have worked on.<p>Particularly, I once needed to stream video from a UAV to multiple tablets and phones on a local network to allow collaborative annotations. Since it was a disaster response system there was no depending on external services, which at the time put WebRTC out of the picture (all of the easy to use implementations required internet access to use existing signaling services).<p>We ended up using MJPEG and then later a JavaScript implementation of a MPEG-1 decoder. This library certainly would have made my life a little easier at the time!
Video decoding in JS is very impressive - really highlights the speed of modern interpreters. I especially love that a Björk track from the 90's is featured.<p>I recently worked on a personal project which had to play back .webm files, and I used a similar utility:<p><a href="https://github.com/brion/ogv.js/" rel="nofollow">https://github.com/brion/ogv.js/</a><p>It decodes .webm files and plays them in the web. I believe it's also used by Wikipedia to play bag Ogg files.
Yet another people who cannot correctly decode video. Videos are not in sRGB color space and must be converted to it for displaying in browser. Also videos do not use full range 0-255, instead they use narrow range 15-235 where color (15, 15, 15) means black and (235, 235, 235) means white; this should be converted to the full range which is used in web-canvas.
I remember toying with this idea when I was doing some web-based slot-machine mobile games.<p>We had a ridiculous amount of assets(mostly animations) that had to be compressed, because one of the sales representatives noticed, that it's impossible to play any of the games if you're connected to a 2G network.<p>Eventually we didn't go with this solution, because it considerably reduced battery life and made the devices heat up too much.
This is really cool! But the compression quality of MPEG1 is really nowhere close to h264.<p>If you're interested in this sorta thing, try taking a look at Broadway JS: <a href="https://github.com/mbebenita/Broadway" rel="nofollow">https://github.com/mbebenita/Broadway</a><p>Here's a simple demo page they have setup: <a href="http://mbebenita.github.io/Broadway/foxDemo.html" rel="nofollow">http://mbebenita.github.io/Broadway/foxDemo.html</a><p>Its entirely possible to use WebSockets to stream H264 to a browser and decode using broadway, and the performance is pretty good, even on mobile.
This has also opened up some awesome new browser experiments, such as playing GTAV in the browser (on an iPhone!)<p><a href="http://phoboslab.org/log/2015/07/play-gta-v-in-your-browser-sort-of" rel="nofollow">http://phoboslab.org/log/2015/07/play-gta-v-in-your-browser-...</a>
Cisco's got a royalty-free codec that would let you decode like it's 2017. <a href="https://github.com/cisco/thor" rel="nofollow">https://github.com/cisco/thor</a>
This is very cool!
In 1999 my degree final year project was to implement an mpeg decoder in software.
My only source of information was the MPEG technical reference manuals.
It took me 3 months to be able to decode my first frame.
It ran at less than 10fps on an AMD K6, but I learn a lot about video and compression.
The talk about JSMpeg is an awesome learning experience. <a href="https://fronteers.nl/congres/2015/sessions/jsmpeg-by-dominic-szablewski" rel="nofollow">https://fronteers.nl/congres/2015/sessions/jsmpeg-by-dominic...</a>
Watch out! Some of this code may be GPL-encumbered. The decoder for JSMpeg is based in part on "Java MPEG-1 Video Decoder and Player" [1], which is licensed under the GPLv2. I am not a lawyer, but an argument could be made that the sections of JSMpeg's decoder that are directly ported from that project are a derivative work.<p><pre><code> [1]: https://sourceforge.net/projects/javampeg1video/</code></pre>
I notice that the demo video stops when I switch tabs. Is this by design or by accident? Can I use JSMpeg but have it play in the background? Another thing; can I have video controls?<p>PS: That video has a very late nineties, early double-ohs feel to it indeed. Good choice of video :)
I don't know where they get the "5 seconds" of latency for dash videos. There's definitely a startup latency, but it's not 5 seconds, and can be avoided with some simple techniques.
It is incredibly hard to stream video from say, a Raspberry Pi to the web in a way/format that's easy to consume on multiple devices or using just the browser. This is awesome.
This begs the question, which codec is optimal in terms of "cpu-cycles-to-decode per second" for a given image quality ( for some subjective measure of quality)?
You can actually do this with H264 as well. I did it for a hack-a-thon a couple months back. We are actually looking at doing this in production for a video streaming on an internal network now that NPAPI is deprecated.<p><a href="https://github.com/colek42/streamingDemo" rel="nofollow">https://github.com/colek42/streamingDemo</a>
Awesome work.
I´m using it for an e-learning/robotics platform for low latency live streaming where it does a great job.<p>I´d like to know how reverse playback could be achieved.
Is there a way to "undo" a P-Frame calculation, or is a second (reverse) mpeg file a possible solution?
I used JSMPEG to process a live 360 camera feed and then a canvas to convert the output to the format to work with a google cardboard.<p>I was pleasantly surprised with the quality of the output and speed of which the devices could decode and render the new output.
This stutters a bit on my 2009 Macbook. If I weren't plugged in it'd probably kill my battery really fast.<p>It's a nice hack to get this kind of video on the iPhone, but somehow I feel that for decoding video JS is a bit high on the stack.