Why not just h264 (or VPX)? Tweet

[Piezas]

I'm trying to figure out the rationale for the custom video encoding scheme. The cards the system runs on natively encodes h264. And while you can decode video on the browser in javascript, you typically burn ALOT of energy doing that. Which means either you're on a more powerful machine to begin with (and in that case it probably has some decent level of graphics). Or you will be really burning the battery on a mobile doing software decoding in an interpreted language (that typically has hardware video decoding of h264).

Is ORBX completely open source and royalty free? That could be compelling. Are the low latency settings for NVENC too low quality?

Thanks,

[Goldorak]

I'm trying to figure out the rationale for the custom video encoding scheme. The cards the system runs on natively encodes h264.

Hardware ASIC is not an option if you wish to stream on a cheaper CPU instance or, need to deploy in an AWS region that doesn't have G2 instances.

And while you can decode video on the browser in javascript, you typically burn ALOT of energy doing that.

WebGL is used for much of the decoding. With WebGL 2, the entire decoder can be offloaded to pixel shaders, even on mobile devices, with performance matching or surpassing dedicated HW decoding.

Is ORBX completely open source and royalty free? That could be compelling.

if you mean the built in ORBX video codec, and the ORBX container format, then yes we're working on a GPL ORBX video decoder:

http://news.cnet.com/8301-1001_3-576159 ... -now-free/

ORBX streams and files may contain more than video. For example, Octane scenes.nodes are exported as ORBX files, which can be interchanged between any 3D apps with an Octane 1.5+ plug-in support. Down the line, compute kernels and scripts may also be in an ORBX container or stream. Also, ORBX files and streams can wrap 3rd party media or data (e.g. H.264).

Are the low latency settings for NVENC too low quality?

The quality of NVENC is actually very good for H.264 encoding. Although not exposed directly on the AMIs, we support the use of NVENC in order to send H.264 video within an ORBX stream to a native client (like a legacy set top box).

This is not the right approach for browser based 'zero client' playback. Low latency H.264 decoding in hardware is not directly exposed to the browser via JavaScript. Secondly H.264 has no support for elements we require for complex Octane Render streams that leverage local WebGL compositing/ post processing: depth channels, deep pixel data, 12-bit color, alpha/coverage, HDR, etc.