ORBX and the Future of Codec Innovation

ORBX may change how we develop codecs from now on.

There’s a new codec in town, and its name is ORBX. Its uniqueness? It has a JavaScript implementation suitable to run on modern browsers. Ars Technica provides a good explanation of the codec and its possible usefulness. I am not going to repeat it here, but rather focus on long term implications.

I am belaboring here a lot about WebRTC and how it changes what VoIP is. WebRTC does that by enabling web developers to write VoIP apps within browsers, but at the end of the day, the codec itself is left in the implementation hands of the browsers – no way to improve it, modify it or change it. ORBX is different in that it takes the video codec itself and makes it something that is editable in the web application code.

Coming from a video company in my past, I am rather skeptic regarding the capabilities of this codec and the comparison made between it and H.264. The things that don’t fit?

• It is a decoder only. The encoder is not written in JavaScript as far as I can understand, and won’t run in the browser. The reason for that is probably the fact that encoders are much harder to implement as they hold most of the smarts of the codec and they are loaded with heuristics – it is where differentiation between codec implementations are found.
• If H.264 performs worse than this one, then the specification of this codec has some newer coding tools that aren’t part of H.264 but probably can be found in H.265. It can’t run faster than H.264 in decoding, especially when parts of its code are implemented in JavaScript.

That said, it is probably only a matter of time until the notion of implementing a full-fledged video codec on top of the browser using Java Script becomes a reality. And when that happens, I think we will see the following power shifts occurring:

1. There will be no more talks about mandatory codecs in standards. Downloading the codec required for a specific use case will be a trivial operation – think how much grief it could save us in the current situation of WebRTC mandatory video codec debates…
2. Services will be able to differentiate on the media quality by opting for a better/more optimized/unique codec implementation that is used in their service only
3. Codec implementations in the browser will require a special breed of developers – low level codec developers that write code in high level JavaScript (as opposed to assembly and C)
4. Development of codecs will become a rapid process that doesn’t require arduous standardization procedures. The basic math required for codecs will continue to be specified and then implemented on the browser level through WebGL and other such APIs, but the actual codec will be implemented on top of them – similarly to what OpenMAX DL is trying to achieve

If this comes to fruition, it can open up a whole new ecosystem and power plays, where differentiation and innovation can spur further in the domain of media processing.

It is a brave new world out there.

And I am probably getting too old for it already.