7 ms·
Are video codecs written in JavaScript really the future?
- pjmlp 13y agoI wonder how much CPU it really uses. The Firefox PDF viewer always makes my CPU usage jump almost to the top.
- shacharz 13y agoIs the major advantage of ORBX.js is that it can be decoded by leveraging webGL? isn't that also possible with VP8/H.264?
- jfb 13y agoIf you're stuck using a software decoder, I guess it's cool that you can use WebGL?
- KaiserPro 13y agoh.264 yes. VP8 not so much.
- azakai 13y agoExperiments with decoding of H.264 in JS+WebGL were done in the Broadway project, and while (as mentioned in the article) reasonable frame rates in JS alone were achieved, WebGL was not a huge benefit. The problem is that H.264 was not designed to run in a massively parallel manner like GPUs expect. There is too much stuff that is serial, so you must run that on the CPU. But a new codec like ORBX.js however can be designed to run efficiently in WebGL, that is what is interesting here.
- StringyBob 13y agohttp://en.wikipedia.org/wiki/Betteridges_law_of_headlines http://en.wikipedia.org/wiki/Betteridges_law_of_headlines It's quite hard to argue against commoditised hardware codecs, particularly when the decoder is a low power mobile device. It's one of the main reasons h264 is going to be around for a long time...
- KaiserPro 13y ago+1 There is a massive amount of high quality content, encoders and transport tools. Even when h.265 is properly ratified its going to be at least 2 years before we see mature tools/content.
- jychang 13y agoYour green username indicates you're new here, so a tip: Don't say "+1", but just upvote.
- leeoniya 13y ago"We spoke to OTOY, and the company told us it has no immediate, specific plans to publish it openly. That's not to say that the company is necessarily opposed to doing so; rather, it's not sure how to do without undermining its commercial products." ah, thats why i couldnt find it on github. and oh :(
- randyrand 13y agoIf it is decoded in Javascript on the browser (so... source code), can't we figure out how to decode and encode the codec fairly easily? Or would using the codec still be a copyright violation even if it is reverse engineered?
- battwell 13y agoMinified js isn't much easier to reverse engineer than compiled native code.
- daeken 13y agoI've spent most of my life reversing native code, and I've also reversed a good deal of minified JS. The latter is many, many orders of magnitude easier and less time-intensive in every case. Now, with things like Emscripten and Asm.js that will change (since the JS is effectively compiled native code), but it still will be easier due to the fact that, for example, you don't have to worry about code-data separations you have to worry about in most native code.
- leeoniya 13y agothe whole point is to have an open codec. if you have to reverse it, not only are you breaking the ToS/EULA, but you're much better off just using a natively installed codec.
- wmf 13y agoPrevious discussion: https://news.ycombinator.com/item?id=5653531 https://news.ycombinator.com/item?id=5653531
- Shorel 13y agoSadly, only focused on the 'games streaming' aspect.
- KaiserPro 13y agoI can understand the appeal, however its just not that feasible on low powered devices(Yet). Most mobiles (most things videos infact) have some silicon dedicated to h26x decoding. Using that silicon is a massive order more efficient (both power and CPU/GPU) Its also more reliable. The other thing to note is that if ars is correct and that it only uses I-frames only in some cases, its not going to be bandwidth efficient. That's one compromise you can't really make in mobile land. Its also going to require two separate streams (one for each class) One last thing, I've not actually seen any output "in the flesh" as it were. VP8 was supposed to be wonderful, but in fact its almost a clone of h264, just with marginally worse performance. (another thing, its actually really hard to make an HD player from scratch. You wouldn't think it but putting frame on screen in a timely and smooth manor is really not trivial.)
- smith7018 13y agoWould you mind going a little more in depth about VP8? Last I heard it was supposedly amazing but that was awhile ago.
- w0utert 13y agoWhat more is there to say about it? It's fundamentally almost exactly the same as H264, minus a few features that would make it too vulnerable to patent litigation, plus a few minor additions that are meant to patch up the efficiency lost by excluding some of H264's features. For web video VP8 performs about the same as H264, for high-bitrate/high quality (think Blu-Ray/Full HD) it performs decidedly worse because it doesn't have most (any?) of the advanced features in H264 main/extended/high profiles. The one big downside is lack of widespread hardware codec support. There really isn't anything 'amazing' about VP8, except that some people think it fixes something about video coding because it is 'more free' than H264, which IMO is vastly overstated. In real life, for 99.9% of people (including those offering commercial video products), the difference is practically philosophical.
- KaiserPro 13y ago+1 this ^
- bmuon 13y ago> H.264 video is abundant, and is unambiguously "the winner" of all the current major video codecs > The viability of watermarking as an alternative to DRM is also speculative conjecture (...) In spite of the changes in the audio market, the video market has remained firmly in favor of DRM A week-old demo and the author is already saying it doesn't have enough market share to be viable.
- epeus 13y agoYes they are, because existing video codecs are based on 1980s signal processing ideas, and increasingly video starts out as being 3D models that are naturally better suited to a trimesh and textures approach instead. I wrote about it here: http://epeus.blogspot.com/2013/05/finally-some-progress-in-video-codecs.html http://epeus.blogspot.com/2013/05/finally-some-progress-in-v...
- hnha 13y agoWhat are you talking about? Film is 2D. How do you imagine it to suddenly be "encoded in 3D"?
- KaiserPro 13y agoUsing 3d space to represent movement of the textures. Currently a frame is split up into blocks, and they are moved about in 2d (X&Y). Using a 3d model of the movement would theoretically gain you some savings, as it would require less refreshing of the moving blocks.
- epeus 13y agoQuite. You can define a textures+trimeshes+motion format and have the decoder be well defined, then have encoders compete to do better, as we have seen with the 2d codecs. Clearly starting form something in GL, like a game walkthrough (How much of youtube is that?) is easier than starting with Bladerunner. A Pixar movie would be somewhere inbetween.
- cromwellian 13y agoObject-based encoding has long been discussed within the MPEG community. MPEG-4 included VRML as a sort of hack for scene based compositing and Structured Audio Orchestration Language et al, as a parallel. I saw early whitepapers where they had planned even to do things like recognize people's faces, and deduce geometry, thereby separately compressing a person in the foreground vs background (use case: conference calls, news anchors, etc) As for whether it is possible to deduce 3D structure 2D, there's been some progress in that regard, check this out: http://www.youtube.com/watch?v=CZiSK7OMANw http://www.youtube.com/watch?v=CZiSK7OMANw
- zmanian 13y agoPart of the question about the Obex technology is where should the computational cost of video transmission be born? Client side or on the server side. Decoding in general purpose compute is expensive for client devices in comparison to codec specific hardware. Otoy's goal is to make encoding computationally inexpensive on the server side. This makes applications like per client frame by frame watermarking and low latency encoding far more scalable than other solutions. Otoy is trying to explore the market potential of inverting the typical encode/decode cost model so that rather than encode once -> decode many. It becomes affordable to encode on a per client basis.
- btbuildem 13y agoAs client devices grow both in computational power and sheer numbers - I think scalability will be facilitated by offloading at least some of the heavy lifting to the client.
- georgemcbay 13y agoThat makes sense if you just consider computational power, but what about bandwidth? The reason we make these fancy video encoders in the first place is to make the data to send much smaller, and while we all have plenty of power on desktops, laptops and mobile is catching up quick, bandwidth still mostly sucks, at least here in the US.
- Strilanc 13y agoIt seems like easy access to the same video with many different watermarks would make it easy to find the watermark, or at least easy to destroy it? Can you still identify who shared a video, if the shared video was created by averaging ten copies with different watermarks?
- smiddereens 13y agoSure, why not.
- Shorel 13y agoAs long as this means no more flash, it's a welcome improvement.
- ianstallings 13y agoThis is fine but the real reason h.264 is so well entrenched is because the whole industry supports it at the hardware level with onboard chips and IP cores. This is particularly important as mobile devices become prevalent. Hardware decoding is essential to reduce energy usage and improve batter life.
- shmerl 13y agoVP8 is catching up in modern SoCs. So H.264 won't have that advantage in the near future (it still has it now, given the existing hardware base). Some things need to be clarified first though, like recent Nokia's patent sabotage to VP8. Not sure what is going on with that.
- B-Con 13y agoIn all seriousness: Why? What do we gain from doing the decoding in JavaScript, besides the "cool" factor? I can see how this would allow more flexibility, since a codec could be downloaded at run-rime, which would remove the need for media to only be packaged in codecs with native, cross-browser support. But is there any chance this could be even close to as efficient, CPU or power-wise, as the current standard native browser codec support?
- gluxon 13y agoThe power in this is that JavaScript is extensively portable and very consistent across platforms. There are no issues with cross platform support that plagues C++ and to an extent, Java's JVM. There's no possibility of platform lock-in, which happens for .NET applications. I don't like how this article is written at all. It leaves a bias afterlook that Mozilla's goal here is to create a toy. JavaScript is the fastest interpreted language and plans are out to make it even speedier. There's a reason why "the future" is emphasized. Perhaps I am biased as a Node.js programmer, but I do believe this is a good thing. JavaScript is seriously pretty sweet. I do like the design of the language. There are features that outblow many other languages.
- simfoo 13y ago> JavaScript is the fastest interpreted language and plans are out to make it even speedier. Citation needed
- gluxon 13y agoWith JIT compilation, asm.js, tracing, it is hard to argue against. A long fought browser war really brought out the maximum capabilities of the JavaScript engine. http://en.wikipedia.org/wiki/JavaScript_engine#Performance_evolution http://en.wikipedia.org/wiki/JavaScript_engine#Performance_e... asm.js promises speed 2x slower than native code. For interpreted code, that is amazing.
- gcr 13y ago
- ndesaulniers 13y ago> The use of WebGL and shader programs may improve the power efficiency somewhat, but they are still inferior to the dedicated motion video hardware found in all modern GPUs. Um...what? Last time I checked WebGL ran and "shader programs" ran on the GPU. What am I missing?
- p_l 13y agoThe actual decoding passes don't translate well to shader architectures, so GPUs include custom circuitry to handle various transformations involved in decoding.
- ndesaulniers 13y agoThe author works for Microsoft. The proposal to use watermarking is in direct contrast to Microsoft's PlayReady DRM implementation. Passing off a conflict of interest as news.