7 ms·
JSMpeg – Decode It Like It's 1999
- amelius 7y ago> 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 7y agoA 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.
- nicoburns 7y agoA lot I would think. It was using "150%" cpu on my 2015 MacBook Pro.
- dusted 7y agoThis 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.
- PostOnce 7y agoNot stressing my 5 year old laptop out too much.
- dschooh 7y agoIt'll use shaders if WebGL is supported and enabled: https://github.com/phoboslab/jsmpeg/blob/master/src/webgl.js https://github.com/phoboslab/jsmpeg/blob/master/src/webgl.js There is also a site to test features and their impact on performance: https://jsmpeg.com/perf.html https://jsmpeg.com/perf.html
- Crinus 7y ago> rather than a practical solution. I have a very practical solution for you: bypassing the autoplay restriction for ads.
- throwaway55554 7y agoThis would be very user hostile.
- jmkni 7y agoOhh that's great! Terrible! But great!
- aeharding 7y agoThis is why videos are allowed to autoplay if muted. Otherwise sites would use GIFs or something like this, which is much less efficient.
- Crinus 7y agoWell, this allows to autoplay even if not muted :-P. https://jsmpeg.com/perf.html https://jsmpeg.com/perf.html
- tomhoward 7y ago> it's just a proof that it CAN be done Which is a perfectly valid reason to build something. But this project is 6 years old (almost to the day, according to Github) and has over 3700 stars, so it seems to be a bit more than a mere novelty.
- speps 7y agoStraight from the minified version: > JSMpeg.Renderer.WebGL.IsSupported()?new JSMpeg.Renderer.WebGL(options):new JSMpeg.Renderer.Canvas2D(options); Not sure why you didn't check if it supported WebGL or not.
- larvaetron 7y ago> it's just a proof that it CAN be done, rather than a practical solution. Thankfully this is Hacker News, not Practical News.
- SmellyGeekBoy 7y agoWow, 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.
- anovikov 7y agoNow 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 7y agoHow much? Probably only 25-50% more? It's hard to guess, but I imagine it isn't more than a factor of 2.
- ahartmetz 7y agoI'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 7y agoanovikov and I are referring to filesize.
- eyesee 7y agoIt's more like 5-10x better at the same quality vs. h.264. MPEG-1 is 30 years old. The available computational capacity along with the tremendous investment in algorithmic research in that period cannot be understated.
- anovikov 7y agoAt least by a factor of 4 and by a factor of 10 in some conditions. MPEG-2 is very processor efficient but in exchange for very low bandwidth efficiency. Today we watch full movies in 720p and decent quality <1GB size, and in MPEG-2 in late 1990s, 2 video CDs (also ~1GB) were needed for a crappy grainy VHS-style movie. Nobody was much pissed because alternative was VHS itself.
- RantyDave 7y agoExcellent. Goes nicely with the Python implementation of ZFS from the other day.
- ryanmjacobs 7y agoI 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.
- detaro 7y agoInteresting project! Curious what exactly you tried - H.264 is a codec, and there's a bunch of ways of delivering it to the client (HLS, WebRTC, some have build WebSocket-based streaming, ...), and I'd expect that the main latency is hidden there, not in the decoding?
- ryanmjacobs 7y agoOf course. FFMpeg was used consistently on our backend; we cycled through various codecs to find the best one for our purpose and changed the frontend library accordingly. And I think you're right on the encoding latency. I believe that H.264 buffers a little bit before it makes a decision on how to compress the frames, where as MPEG1 doesn't? I could be completely wrong but my gut is telling me that MPEG1 is basically independent, slightly-modified JPEG frames.
- josteink 7y ago> I could be completely wrong but my gut is telling me that MPEG1 is basically independent, slightly-modified JPEG frames. Not that simple, but not that far off. Basically MPEG1 has key-frames (“JPEG” frames) and (forward) delta-frames (diffs). From my understanding H264 has many improvements, including reverse delta-frames. My guess is that disabling those in the encoder will improve real-time capabilities.
- truth_seeker 7y agoNot 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 7y agoI 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 7y agoAfter 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
- userbinator 7y agoKeep 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.
- clouddrover 7y agoogv.js does Theora, VP8, VP9, and AV1 video and Opus and Vorbis audio: https://github.com/brion/ogv.js https://github.com/brion/ogv.js https://brionv.com/log/ https://brionv.com/log/ A demo which lets you select various codecs to try out. You can, for example, play 720p VP9 video in Safari with the WebAssembly build of the decoder: https://brionv.com/misc/ogv.js/demo/ https://brionv.com/misc/ogv.js/demo/
- zbobet2012 7y agoH.265's biggest changes are probably a change from fixed macroblocks (basically a fixed grid) to a tree based structure called a coding tree (see this paper for details: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.352.1947&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.352...). It includes 8k and HDR color support (in 10 bit in v1 via main 10 profile, and 12 and 16 bit in v2). In addition it moved from 9 prediction modes to 26.
- dan_hawkins 7y ago
- Aardwolf 7y agoNeat! One disadvantage I discovered: it stops playing when you go to another tab
- justinmchase 7y agoThat can be an advantage based on what video you may be watching and where ;)
- tomhoward 7y agoAlso discussed 2 years ago: https://news.ycombinator.com/item?id=13549877 https://news.ycombinator.com/item?id=13549877
- colek42 7y agoThis 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
- scarlac 7y agoCould 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?
- farindk 7y agoSimilar 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 7y agoInteresting how the FPS keeps raising over time, possibly the browser progressively optimising code hotspots?
- CountHackulus 7y agoI've used this in a production project I can't really talk about. It performed super well and I was consistently impressed.
- Joyfield 7y agokb != kB.