ProEXR creator comes up with MOX, new open file format for movie production

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:

Standards comic at XKCD

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 iinterested in more details about the project, we suggest reading an in-depth interview with Brendan taken by Mark Christiansen for Pro Video Coalition.

Was it useful? There's more:

7 Responses. Comments closed for this entry.

  1. It took PNG more than 10 years to be correctly supported by most apps (IE6 and Paint Shop Pro 7 couldn’t read its alpha channel), and most apps (even FOSS ones!) still doesn’t support metadata for it.

    Still, I’m rooting for this format to gain traction, at the very least it will be a good common format for FOSS video editors.

  2. libavformat supports reading many MXF files and writing a few variants of it. So, nearly all FOSS video editors that use a modern libavformat has some support for it.

    It will be nice to add support for free/open codecs and image formats to MXF. Then, a MOX plugin can be made for the proprietary tools that will facilitate greater interchange (at least for media assets) with high fidelity, consistency, and ease-of-use. Brendan’s approach will allow him to make plugins for proprietary tools without the heft and licensing of Libav, FFmpeg, or gstreamer as a dependency.

  3. Hey Alex, thanks for writing about MOX. Skepticism is a healthy thing.

    I’m hoping to encourage free/libre software to support MOX by making it really easy to do so. As I often say, OpenEXR is the example I’m following.

    If you check out the OpenEXR documentation, basic reading of a file can be done in just 7 lines. Writing one can be done with just 3. Their library handles all the details of the codecs and container. The more time-consuming part of adopting OpenEXR is adding it to your build system.

    As a movie format, MOX will need a line or two more to specify which frame you want or which audio sample, but it should still get done with a pretty small number of lines if you just want the basics. Again, I foresee the larger part of the work will be getting libmox and its various dependencies integrated into a build system.

  4. This seems like a great initiative to me. I’m always open to improvements for free editing, and if MOX happens then serious open source editors will be able to integrate it easily. It only gets messy, so far as I can tell, when the corporate folk get involved and start mucking up an open format with all their proprietary add-ons.

    OpenEXR is definitely the example to follow. It has remained pristinely open and as a result, actually works on any system just as it was designed.

  5. Wouldn’t it make more sense to try to update Ogg Vorbis, WebM etc to do what you need? It will take years for yet another standard to gain traction.

  6. The native Shotcut mlt files can now be converted to CMX 3600 EDL files with:
    Which then can be imported in ex. Blender, Lightworks or Resolve.

    The first steps has been taken to convert native Lightworks files to EDL or MLT (Shotcut) here:

    And here’s a python binding for AAF:

  7. When it comes to these sort of projects i am always a pessimist. It will be interesting to see how this project develops but to me the 30k received from crowdfunding doesn’t seem like enough. Even if the specification and software are successfully developed, adoption of the format will be an incredibly slow process(if at all).
    But hopefully i am proven wrong :)