The minute they mention MPEG, I already know whats going to happen - Licensing. Spoken by a dev that didn't incorporate video, due to licensing, not technical reasons. The open bit is just the draw.
See my post above. ORBX schema and formats submitted to mpeg must be usable by anyone and everywhere with only an MIT license (same as lua which we use script nodes in the graph). I was told this is fine, but that they need it as a tier 1 MPEG license (their equivalent as I understand it).
I may sound like a skeptic, but I am fairly sure that if MPEG have an interest in this, it is in order to license it.
If not now, then later. In my opinion, this would be MPEG getting their teeth into a new tech, in order to either license it now, or wait until it has traction and then license it.
Open source doesn't mean royalty free (though I have no idea if this format would be royalty-bearing).
There are open source implementations of various MPEG and JPEG codecs, but they still carry a licensing fee to use them. Most people who don't use Linux don't realize this (installing Linux and trying to deal with av codecs is a quick education in the difference).
ORBX framework should be like Lua or luaJIT -i.e. MIT license. What is built or done on top of that and how it's licensed to others is up to the creator or implementer to decide, assuming they have such rights already.
I need to download the latest version that was submitted to MPEG for the file and serial data format and get it on OTOY.com like the 1st doc (intro PDF) linked in my post above. Will share a link as soon as that's done. The container and stream are just one layer, the full node schema and module system is mapped out on docs.otoy.com for users and developers.
We're working on a flat C API for ORBX script nodes which will (we hope) leverage WASM+WEBGPU/VK to add novel functionality within the node graph itself instead of needing it to be in an arbitrary external renderer. This was how we first implements ORBX1 video in pure JavaScript back in 2013
Note that Graphs can further 'render' a scene to valid glTF/mesh and volume formats, not just texture/image output buffers.
I don't think glTF will be able to fully replace alembic/FBX soon in the schema
sadly, based on last KHR discussion at siggraph (I understand the reasoning, do not going to advocate they change it); glTF is still a useful asset format for proxy volumes or baking to webgl pipelines.