ProEXR creator comes up with MOX, new open file format for movie production
Brendan Bolles launched an IndieGoGo campaign to sponsor creating MOX — a new open source movie format for video and film production. But the industry seems split over this idea.
Why another file format?
In Brendan’s opinion, every already existing movie file format falls short for at least one reason, either being not cross-platform, or being patent-encumbered, or not supporting higher bit depths and lossless compression. E.g. both Apple ProRes and QuickTime would work very well as intermediate file formats, but neither are open or cross-platform.
What is MOX, exactly?
The idea with MOX is to take an already existing MXF container and strip it down to standardize codecs and metadata to avoid vendor-specific “dialects”. The next stage would be creating plugins for popular authoring applications to use this file format.
The original proposal includes Dirac, OpenEXR, DPX, PNG, and JPEG, so that both video and VFX target groups of users would be covered. Audio codecs are supposed to be FLAC, Opus, and raw PCM.
The reception of the project
So far we’ve seen both positive and negative responses regarding the idea. At this point, some background information might be helpful.
To begin with, people who started this are not exactly some random folks on the Internet.
Brendan Bolles started out as matchmover in Jeepers Creepers II, then worked as digital artist in Sin City and Sky Captain and the World of Tomorrow, then he did compositing in Grindhouse and Planet Terror.
He also has substantial track record of creating plugins for proprietary software to support open standards: from ProEXR for Adobe Photoshop and After Effects, to AdobeWebM project which brings WebM and WebP support to Premiere and Photoshop respectively, to AdobeOgg which adds Ogg Vorbis and Ogg Theora support to Premiere.
In other words, Brendan has a lot of hands-on experience with various containers and codecs as both user and developer.
His initiative was praised by many people, including Stu Maschwitz, creator of Magic Bullet Looks and, as it happens, Brendan’s former employer at The Orphanage studio:
Imagine of ProRes wasn’t controlled by Apple. Imagine a movie file that played back with the correct gamma on every computer. Imagine multi-channel, high-bit-depth movie files for VFX collaboration. Imagine a camera that shoots both a lightly-compressed, ungraded log digital negative and a compressed edit proxy with the on-set LUT baked in—both in the same file.
Most of the criticism so far boils down to these several points:
1. Completing the spec might take too much time. At this point, MOX is more of an idea at the stage of research. It’s also not the first project of this kind. For instance, MXF Application Specification (AS-07) has not yet been completed after 5 years of work and is currently at the draft review stage. Since there will be public discussion of MOX, drafting and completing the spec might take longer than expected.
2. Getting MOX accepted by the industry. Pretty much every skeptic recalled this undying XKCD classic:
On a similar note, one of the users of The Foundry’s forum noted:
We use MXF where I work and then convert to .mov and .mpg for delivery. If it were possible to use MOX from start to finish, that’d be nice, but I don’t see it happening. We are using Leightronix UltraNEXUS-SDI for our system and it’s pretty strict on file format. Getting those systems to use a format will be a huge undertaking. The industry standard for broadcast is mpeg and even though I don’t like mpeg, that’s what it is. This would be good to pass around while working on the project, but not for final delivery.
This part of the skepticism is partially debunked by the fact that, as noted above, Brendan has a lot of experience writing plugins for popular authoring software. For instance, ProEXR has quite a lot of users in the industry, but it’s an implementation of a pre-existing file format. How many users Brendan’s other projects have is another story.
3. Not using Matroska. A lot of critics point out that Matroska is already open, supported by many tools and feature-wise should just fit the bill, hence no need to come up with another standard.
First of all, Brendan specifically says:
I am really trying to avoid creating any new standards here. Technically, MOX will be what is referred to as an “MXF Application Specification”. Just like WebM is simply a re-branding of Matroska + VP8/9 + Opus/Vorbis, MOX will just be MXF + specific codecs + metadata conventions.
Secondly, Brendan has a few technical issues with Matroska:
Matroska has a few limitations that make it unsuitable. A really big one is the way it does timing, using integer timestamps with a fixed timebase. This is totally fine for a playback format, but you can’t seek audio precisely enough for video editing. In my WebM plug-in, I deal with this by scanning all the audio in the file and mapping Matroska’s course timestamps to the actual audio sample numbers.
I asked the creator of Ogg about his container, but he said it wasn’t well-suited either, for different reasons. MXF is the one container (that I know of!) that was created for production purposes, so it seems like a natural choice. It does a whole bunch of things that won’t be part of the MOX spec, but it’s nice to know they could be adopted.
4. The initial choice of codecs makes little sense. Some critics pointed out that Dirac as the only video codec proposed by Brendan is not exactly suitable:
- not many apps support it and some might have problems supporting lossless encoding/decoding;
- not good enough performance, compression worse than the one in J2K.
One substitution that was suggested is FFV1 which performs ca. 10 times faster than Dirac and compresses better. Since it’s supported in FFmpeg/LibAV (where it was conceived), it’s widely supported even without some vendors even knowing it.
To this Brendan replies:
I am not completely married to any of the specifics mentioned in the campaign. If it turns out something doesn’t work the way we expect or a better solution is found, then I will switch to that solution and any standard I have written up will have to be re-written.
I am interested in any video codec that is open source, patent-free, and has something to offer that the others don’t. My list of codecs is not set in stone. I certainly intend to try out FFV1, ImageZero, and others.
It is even conceivable that there would be a problem with the MXF container and we would have to use another, which would void any spec we had written beforehand. I don’t anticipate this happening, but that is why I don’t want to devote time to a spec before the project is funded and software is being written.
Some concerns have also been voiced that it takes four file formats — EXR, DPX, PNG, and JPEG — to cover lossless and lossy use cases with all bit depths options.
**5. Overdesigned metadata support. **Among technical requirements Brendan lists color space metadata in form of ICC profiles, named color spaces like Rec. 709, gamma & chromaticity values, OpenColorIO configuration information, and embedded LUTs.
There is a notion in part of the community that stills should be manipulated in a scene referred model, not display referred. On top of that. some people pointed out that too many types of metadata would likely cause conversion issues, and some of the proposed types might not make sense in movie production context.
Brendan, however, replies:
We’re planning to support ICC profiles, because that’s what Adobe uses. I may agree that it would be better if they didn’t, but if someone renders a movie out of After Effects, it would be good to pass along the same ICC profile that AE spits out, not losing anything.
In the OpenEXR plug-in for After Effects I store the ICC profile but also use it to generate chromaticities, which are the standard EXR way to do color.
My philosophy is to try to embed any metadata that may come along and then do my best to translate it to different programs.
Support in free software
Among deliverables of the project there should be a open source library that could be used to create and open MOX files. There is, however, one single problem with that when it comes to free/libre NLE apps: their interoperability is close to zero anyway.
No free/libre software supports AAF. The only existing free non-linear video editor that appears to read MXF files is Pitivi, and the muxer is yet to be ported, so there is no writing of MXF files in Pitivi yet. Even such a simplistic file format as EDL is only supported in Cinelerra and Blender’s VSE. Feature requests for that have been sitting in respective bug trackers for years with not much to hope for.
So, if you can pardon this strike of alarmism, should MOX fly, it’s going to take an unpredictable amount of time till free/libre video editors become interoperable between each other and commercial apps. Unless, of course, the final spec of MOX will be so amazing that plans and roadmaps all around will be adjusted to make some place for it.
Currently the MOX fundraiser is 70% done, with 20 days to go. Further research by Brendan Bolles and actual design of the MOX specification will go in effect once the project is 100% funded. If you are interested in more details about the project, we suggest reading an in-depth interview with Brendan taken by Mark Christiansen for Pro Video Coalition.