None more open. Mox promises to be an open format based on open standards and will include an open source C++ library to ensure that any program will be able to easily support its files now and forever. Can it work?
The issue of file format incompatibility is not a new problem, and the idea of introducing One File Format to Rule Them All is not a new solution. The problem is that while the introduction of a new standard has the potential to solve compatibility problems, if adoption is not near-universal, it can also just muddy the waters even further.
Our topic for today, is whether a current crowdfunding campaign on Indiegogo for a new standard in motion imaging files is likely to help or not. Called Mox (MOX? MoX?), it is intended to be unencumbered by patents and freely available to be implemented by anyone who needs it, avoiding the problems of things like ProRes in Quicktime which is jealously guarded by Apple (though third-party tools can encode it). Mox is intended for use in post production – the people involved are mainly experienced in feature film effects work.
The brief overview of the format given in the crowdfunding documentation describes it as using MXF to contain Dirac, OpenEXR, JPEG or PNG images. This is a similar approach to that used in practically all motion imaging files, including AVI and Quicktime movies (and thus also MPEG-4 (Part 14) files), which generally define a structure which can be used to contain images, sound, timecode, subtitles, and other contents.
The container is often a separate consideration to the codec, with the result that a Quicktime movie can contain images compressed with h.264, ProRes (or in fact Dirac, OpenEXR, JPEG, or PNG). So, for that matter, can AVI, Matroska, or others. The very term “Matroska” derives from the Russian Matryoshka, for the multi-layered wooden dolls, each containing others. This all means that it's possible, using third-party tools, to make a ProRes AVI file. What's more, the Quicktime player application, perhaps more through a feat of good, generalised coding than through Apple's specific intention, will play it.
The limitations of MXF
The choice of MXF as a container for Mox is no surprise in 2014, but perhaps slightly questionable in that Mox seems intended to replace DPX sequences, and DPX sequences are used because they are very simple. MXF, conversely, was an attempt to create a file format that could be all things to all people, but ended up being so complicated that it risks being nothing to anyone.
It is so complicated that revisions to the original specification mainly act to restrict what should be done with it such that there's some vague hope of broad compatibility. Even so, it's generally necessary to know what equipment a given MXF was created on and what it's intended to do before it can be reliably used, and that's a pretty damning indictment of something which was specifically intended to be self-describing. So labyrinthine is MXF that vendors have released applications including a scripting language to allow various options within the file format to be trialled and tweaked.
So-called “golden files” exist which are intended to exemplify and standardise an MXF built for a particular application, which will have been manually reviewed for correctness by an expert. There are ten “operational patterns”, most of which are each a separate SMPTE standard unto themselves, and twelve “generic containers”, which describe how to store various kinds of data in MXF, each of which is also a separate SMPTE standard. I could go on, but make no mistake: MXF is a beast.
In defence of MXF, it is mainly used in broadcast news and sports, where a camera will work with a known, stable post production environment. Avid, for instance, seems a big fan. In these circumstances it works well, because issues of compatibility will have been addressed at the planning stage. Most MXF devices that actually exist, which are mainly used in these stable, planned circumstances, work quite happily. In a less static situation, though, where various kinds of equipment might be brought together by owner-operators for short-term projects, there can be problems – and that probably represents a lot more individual projects, if we consider a news channel to be an ongoing single project. MXF is entirely capable of working in a project like Mox, but it will need to be ruled with an iron fist to avoid creating the sort of problems they seem interested in solving.
Regarding codecs, the situation is clearer. ProRes and H.264 are encumbered by corporate interest. JPEG as an intra-frame video codec is not hugely dissimilar to ProRes (or DNxHD, or DV, DVCAM or DVCPRO, or HDCAM), although the latter has modifications for better performance. PNG is suitable for graphic art involving areas of identical pixels. OpenEXR is a topic all of its own, but is already gaining ground in visual effects work, having been developed by ILM specifically to serve in areas where DPX lacks key features.
Perhaps the most interesting choice, though, is Dirac, a pet project of the BBC's R&D department which seems designed to be an alternative to H.264. While OpenEXR has some compression options, Dirac is certainly the option closest to doing that, with both intra-frame and inter-frame modes available. One difference is that Dirac is a wavelet codec, like JPEG2000 (as used by Red) which degrades differently – perhaps better - with reducing bitrate, although it is harder computational work. Dirac has not held up perfectly to H.264 in comparative tests, although it can compete with only a small bitrate penalty.
There is currently no mention of including raw, Bayer-patterned data in Mox. It would presumably be possible to wrap it in a new payload, or one of the existing payloads, although this would only be meaningful in the context of a post chain that knew what it was dealing with as de-mosaic software tends to be per-camera anyway.
So, the Mox project is not necessarily inventing new technologies. New combinations of discrete cosine transform or wavelet codecs, contained within different data structures, can be developed fairly trivially. It's refreshing to see that the project recognises that this is unnecessary, as the parts required to build a usable video file format already exist. The initial appeal is intended to fund the creation of a Premiere Pro plugin, with stretch goals to support other NLEs and effects packages. The key issue, as with any standard, is adoption. Many of the world's technical problems could be solved by standardisation, but with corporate self-interest often working against it, it's a tricky prospect.