
JSMpeg – Decode It Like It's 1999 - mmcclure
https://jsmpeg.com/
======
userbinator
Keep in mind that MPEG-1 was designed to give acceptable performance on the
computers of the time, so it is a far lower complexity codec than those which
came after it, and explains why current hardware can provide acceptable
performance with it even with JS overhead. The standard widely-used codecs
roughly have a history like this:

    
    
        H.261 - first standard DCT-with-motion-compensation codec
        MPEG-1 - B frames, variable rates and sizes
        MPEG-2/H.262 - interlacing, 4:2:2 and 4:4:4 subsampling, other minor features
        H.263 (FLV) - mainly low bitrate improvements, introduction of intra prediction
        MPEG-4 part 2 (DivX/Xvid, etc.) - more prediction modes, some very advanced and little-used features (3D shape coding?)
        H.264 - different transform, even more prediction modes and features
        H.265 - not really familiar enough with this one to say
    

Also worth noting that this isn't a full MPEG-1 decoder, since it doesn't
support B-frames. The justification given in the documentation is "no modern
encoder seems to use these by default anyway", but B frames are what gives
MPEG-1 a significant compression advantage over its predecessor, H.261; so I'd
consider this implementation to be closer to an H.261 with variable frame
sizes and framerates, which is useful enough.

~~~
dan_hawkins
"MPEG-4 part 2 (DivX/Xvid, etc.)" \- did you mean "MPEG-2 part 4 (DivX/Xvid)",
hence the (misleading) filename extension "mp4"?

~~~
banthar
MPEG4 the video codec is
[https://en.wikipedia.org/wiki/MPEG-4_Part_2](https://en.wikipedia.org/wiki/MPEG-4_Part_2)

mp4 the media container is
[https://en.wikipedia.org/wiki/MPEG-4_Part_14](https://en.wikipedia.org/wiki/MPEG-4_Part_14)

MPEG-2 part 4 is some conformance testing specification.

------
ryanmjacobs
I almost did a double take when I saw this project.

We used this library two years ago in HS for some low-latency VR streaming.
And yes, it's a little CPU-intensive so our smartphones got rather hot.

We tried other streaming protocols (such as H.264) but all of them supplied
noticeable latency that made our system disorienting. Only JSMPEG was fast
enough for our purposes. It's a fantastic library for any low-latency
streaming! Highly recommend it.

\---

Anyways, self-plug for our old project: [https://rmj.us/motorized-
live-360-video/](https://rmj.us/motorized-live-360-video/). Basically, the
smartphone's gryoscope controls a remote video camera that streams a live-feed
to the user's headset.

~~~
maaaats
Cool project, similar in spirit as to something I did a few years back as well
( [https://github.com/Matsemann/oculus-
fpv](https://github.com/Matsemann/oculus-fpv) ). It's pretty trippy watching
real stuff live, but your "head" is somewhere else. Cool that it's even
possible to experiment with in the browser now.

~~~
ryanmjacobs
Oh shoot wow that's really cool! Honestly, it's such a weird feeling viewing
through that secondary perspective. I'm glad that someone else also came up
with the idea.

We had a lot of fun by having someone hold the device mounted on a pole,
looking down on the viewer, and following them around the room. This provided
a weird, quasi-video-gamey third-person perspective, like in GTA or some
other.

~~~
netsharc
A friend once walked towards my office while we were video chatting (he was on
his phone). Seeing the video of our office hallway on my screen, and realizing
he was walking to my office disorientated me a little.

And these guys did that with a car:
[https://www.youtube.com/watch?v=nIRUavithF8](https://www.youtube.com/watch?v=nIRUavithF8)

------
SmellyGeekBoy
Wow, that MPEG-1 encoded music video just hit me with a wave of nostalgia -
not the song itself but the encoding!

I remember downloading similarly-encoded (and much worse) music videos at the
time, pausing and resuming over multiple nights on services like KaZaa. Good
times.

------
colek42
This is a really cool project and helped inspire me to write a "streamer"
using ASM.js with FFMPEG on the front end and libav on the back end reading a
UDP stream. You can send the TS packets over the Websocket as a data blob and
decode them on the front with FFMPEG. I was able to get sub 100ms latency
(probably a couple frames) on a local network. I wrote a demo which you can
find here.
[https://github.com/colek42/streamingDemo](https://github.com/colek42/streamingDemo)

------
truth_seeker
Not bad. I was able to run 1080p trailer of the movie in the following link
with CPU ranging between 32% to 39% on my old MacBook Pro from year 2012.

[https://jsmpeg.com/perf.html](https://jsmpeg.com/perf.html)

~~~
LeonM
I measured the same performance (~35% CPU)on my rMBP 2012 in Chrome under
MacOS.

On my new Lenovo X1X I measured 4% CPU usage with Chrome under windows. Sure,
the X1 has a new CPU, but I didn't expect this performance increase. Is this a
windows optimization?

~~~
truth_seeker
After reading your comment, I tried to disable the "WebGL" option on that perf
web page and guess what ??? CPU usage bumped upto 64%, twice as before.

I think in the case of X1, the GPU card memory must be really good and WebGL
is able to direct computation tasks to GPU

------
farindk
Similar thing for h265:
[http://strukturag.github.io/libde265.js/](http://strukturag.github.io/libde265.js/)
Code:
[https://github.com/strukturag/libde265.js](https://github.com/strukturag/libde265.js)
Difference is that this is using emscripten to compile the native code to JS.
That was 5 years ago. Today, we would use WASM, of course.

Runs surprisingly smooth, even though a native decoder is clearly superior.
However, there are still nice uses, like adding support for HEIF to the
browser:
[https://strukturag.github.io/libheif/](https://strukturag.github.io/libheif/)
Code:
[https://github.com/strukturag/libheif](https://github.com/strukturag/libheif)

~~~
K2L8M11N2
Interesting how the FPS keeps raising over time, possibly the browser
progressively optimising code hotspots?

------
scarlac
Could this be used in ads instead of native players, circumventing browser
limitations such as auto-play? Obviously, the implementation would have to get
better, but perhaps WebAssembly would make it just bearable enough that ad-
ridden sites would allow them to eat up your CPU?

------
amelius
> JSMpeg can decode 720p Video at 30fps on an iPhone 5S, works in any modern
> browser (Chrome, Firefox, Safari & Edge) and comes in at 42kb gzipped.

What is its power use, versus native decoding?

~~~
untog
A few years ago video tags were very limited on iOS - they would only play
fullscreen and couldn't be autoplayed (which would have been useful for GIFs,
even MPEG1 is more bandwidth effective than GIF).

None of those restrictions remain now, so this is more just an interesting
proof of concept at this point.

------
tomhoward
Also discussed 2 years ago:

[https://news.ycombinator.com/item?id=13549877](https://news.ycombinator.com/item?id=13549877)

------
RantyDave
Excellent. Goes nicely with the Python implementation of ZFS from the other
day.

~~~
josteink
Surely there must be a python interpreter written in Node we can use somehow.

Remember: We need full stack!

~~~
eru
See [https://bellard.org/jslinux/](https://bellard.org/jslinux/)

------
Aardwolf
Neat!

One disadvantage I discovered: it stops playing when you go to another tab

~~~
justinmchase
That can be an advantage based on what video you may be watching and where ;)

------
CountHackulus
I've used this in a production project I can't really talk about. It performed
super well and I was consistently impressed.

------
Joyfield
kb != kB.

------
dusted
This seems tremendously CPU intensive, my fan spun up after two seconds of
playing video. The idea is interesting, but until it does it with GLSL shaders
or something to get that sweet hardware acceleration,it's just a proof that it
CAN be done, rather than a practical solution.

~~~
Crinus
> rather than a practical solution.

I have a very practical solution for you: bypassing the autoplay restriction
for ads.

~~~
throwaway55554
This would be very user hostile.

~~~
Crinus
You mean user engagement will improve, right? :-P

------
anovikov
Now compare the amount of data it consumes vs h264 for the same
resolution/quality... This isn't going to fly. And, WebRTC IS supported on
iPhones now, which kills the main area of use for it.

~~~
vortico
How much? Probably only 25-50% more? It's hard to guess, but I imagine it
isn't more than a factor of 2.

~~~
ahartmetz
I'd guess factor 4-10. Most video codec implementations are heavily optimized
including use of assembly or SIMD intrinsics. So it's not only that JS is
slower for the same code, there are also some optimized constructs that are
not possible in JS.

~~~
vortico
anovikov and I are referring to filesize.

