A long time ago whilst designing MXF, we had a simple problem to solve? How do you make the format efficient? It’s a video format and so there is going to be a LOT of data flying around:
In the physical world, devices like discs, tapes, networks, even USB flash drives have physical limits in the size of a packet that can be stored or moved. For a disc this might be the sector size. For a NAS, it might be the stripe size. For a network it might be the MTU (Maximum Transmission Unit). In all of these cases, you can read and write data that is bigger or smaller than these numbers, but if you want the fastest, best, slickest system then you should match the reading and writing to one or all of these numbers.
“So what’s the problem Bruce?” I hear you ask. Well, in MXF we could not simultaneously optimise the format for all of these different numbers, especially as they change over time. Since 2004 when MXF was first standardised, discs are over 3 orders of magnitude bigger, so any value that we might have chosen would have been wrong. What we did was to add an option to the file format that allowed an MXF File write to say “I have aligned my KLVs to a grid that occurs every 1, or every 512 bytes”. This property known as the KLV alignment Grid or KAG is clearly defined as an optional performance enhancement.
“I still don’t understand the problem Bruce!” I hear you shout. Well, because of the way we write specifications, it’s very difficult to say “If you used KAG then do it this way, but if it’s not important to you then do it another way”. The DPP specification has one such piece of text – it basically says “KLV shall be one”. This forces all decoders to be as flexible as possible and makes no assumptions on the underlying medium. The decoder must work with discs, memory sticks, NAS, SAN and the like. The problem comes if you write the file more strictly so that the performance in a single system goes up. You may want to use a larger KAG in the writer knowing that it will work in the tolerant decoder that has been tested with KAG=1.
In this system, your decoder is more likely to work correctly and quickly. Unfortunately, the specification says “KAG=1”. Any file built with this optimisation and put into the IRT analyser will get an ERROR. This causes worry amongst people who don’t understand that the error is really more like “Warning – the file writer optimised this for performance and your decoder might go more quickly than you expect.” The minutia of specification language written into standards and implemented in tools makes it hard to optimise for many things at once. Fortunately, at AmberFin we are used to such trivia and spend a lot of time trying to get our files right according to the specification and also to make beautiful pictures both quickly and efficiently.
The DPP specification is ready for prime time. The tooling and checking benefits hugely from interoperability testing like the #DPPIOD . Why not download our DPP white paper to find out about the big picture and leave the minutia to us?
