IASA-TC 06 video guideline: digital target format

This is the third of a series of five blogs on IASA-TC 06 by the guideline's coordinating editor Carl Fleischhauer.

The term target format names the digital entity (a file or a bundle of files) that receives and carries the digitised content from a source video recording.  Guidelines for the Preservation of Video Recordings, IASA-TC 06, discusses multiple target formats (with varying levels of enthusiasm) in terms of their ability to support the long-term preservation of video content.

Why multiple target-format options?  Specialists in the field of video preservation have not reached consensus about preferred digital-file formats for preservation. Their mix of opinion reflects the following factors:

• Video preservation practices are not yet mature, format specifications are still being refined, and there is relatively little actual experience.  
• An archive (or the contractor who regularly services an archive) may have an installed equipment base (and related experience) that supports one format but not another.
• For some classes of content with relatively simple payloads, different specialists recommend different options, all of which are perfectly respectable.
• Meanwhile, there are classes of content with relatively complex payloads, e.g., recorded television broadcasts that include embedded binary-coded captions or subtitles, multiple strands of time code inherited from the footage assembled to produce the program, multiple soundtrack channels, and other forms of ancillary data.  To date, archivists have offered few thorough analyses and recommendations for these classes of content.  Different specialists may still recommend different target-format options, acknowledging that some will be unable to carry the full payload, making them imperfect choices.

BTW: readers should remember that formatting in a digital file pertains to both the file wrapper and the encoded bitstream (or bitstreams) that represent the video payload.  Wrappers provide a way to store and, at a high level, structure the data represented in the encoded bitstream. In addition, the wrapper usually also provides a mechanism to store technical and descriptive information (metadata). 

The encoding, on the other hand, defines the way the picture and sound essence data is structured at the lowest level.  For example: Will the data be RGB or colour-difference component?  (Colour-difference component is typically nicknamed YUV; many broadcast professionals prefer the more precise term Y'PbPr if analogue, Y'CbCr if digital.)  If YUV, what is the chroma subsampling? The encoding also determines how much data will be captured: what is the sampling rate and how much information will be captured at each sample? Other encoding features include the frame rate and the bit depth at each pixel or micropixel, as well as data compression, which may be lossless (good!) or lossy (not so good for preservation of old recordings).

There is no widely used set of category terms for the target formats discussed in IASA-TC 06, so we concocted one.  For the first category, we invented the term marketplace wrapper as a lexical convenience.  It is the case, of course, that all of the wrappers in the list may be selected from the same metaphorical marketplace.

• "Marketplace wrappers" with picture as lossless compressed FFV1 or as 10-bit-deep uncompressed, 4:2:2 chroma subsampling
  • Subtype: OpenDML AVI wrapper, FFV1 encoded video.  The OpenDML extension is required in order to support files greater than 2GB.
  • Subtype: OpenDML AVI wrapper, v210 encoded video.  The encoded video type called v210 is the uncompressed 4:2:2 10-bit video bitstream, as typically structured to write to file.
  • Subtype: QuickTime wrapper, v210 encoded video
• Matroska wrapper with picture as losslessly compressed FFV1
  • Subtype: format version that employs Matroska and FFV1 undergoing standardization by IETF, with the specification as developed by the MediaConch/CELLAR project.
• MXF wrapper with picture as 10-bit-deep uncompressed, 4:2:2 chroma subsampling
  • Subtype: format conformant to SMPTE standards and realized in various digitisation systems
  • Subtype: format as described in FADGI specification AS-07
  • Subtype: format as described in the 2013 BBC White Paper 241BBC White Paper 241
• MXF wrapper with picture as losslessly compressed JPEG 2000
  • Subtype: format as described in FADGI specification AS-07
  • Subtype: format as produced by the SAMMA devices, now discontinued but formerly available from Media Matters and subsequently Front Porch Digital

These formats receive considerable discussion in IASA-TC 06 and are the subject of a table that compares their features and capabilities.  At a high level of generality—and, as of this writing—the authors find that the marketplace packages fall a bit short, especially for the carriage of complex-payload video recordings.  At the same time, the three latter categories (Matroska/FFV1 and the varying flavours of MXF) are in varying states of implementation.  This is the subject of a "dilemma" sidebar in the guideline, excerpted (and paraphrased) in the following paragraphs

Marketplace formats.  The "marketplace formats" listed above are well established and widely implemented.  This is a plus, although these formats lack some features that are important for some (but not all) types of video recordings.
Matroska and MXF formats.  The Matroska/FFV1 formats are a little more in a state of "becoming," as outlined in the following bullets:

• Matroska/FFV1: ever-growing use in implementations that predate the final completion of standardization.
  • There is current use in memory institution archives; in the United States, notable examples include the Indiana University and New York Public Library.  This format has been greeted with great enthusiasm, and supporting tools are coming into play prior to the completion of the IETF standardization process, which should reach the point of publication during 2018.
• MXF/v210: thoroughly implemented in generic form, with the refined AS-07 version awaiting implementations in practice.
• MXF/JPEG 2000: in extensive use in several archives in the early SAMMA-profile form, with the new AS-07 profile in initial implementations and use.  
  • The early SAMMA-profile version of this format is in use in some memory institution archives, e.g., the Library of Congress, the national libraries of Norway and Australia, and Libraries and Archives Canada. Some vendors have implemented AS-07, and this process will continue during 2018.  It is worth noting the widespread use of the MXF wrapper by broadcasters and the entertainment industry, often incorporating JPEG 2000 picture encoding, e.g., for digital cinema.  For this reason, many memory institutions allied with broadcasters and the entertainment industry are drawn to MXF-based formatting.

The user communities that work with each of the preceding format categories represent different perspectives and practicalities and they took form at slightly different times.  In 2007, the Library of Congress and the national libraries of Norway and Australia embraced the SAMMA digitization system and its use of MXF and JPEG 2000.  At that time, few memory institutions were aware of Matroska and FFV1, two open source formats that had not yet reached a mature state of development.  The named institutions saw their selection of MXF/JPEG 2000 as consistent with their general stance favouring audiovisual standards from SMPTE and ISO, and a good fit for their traditional acquisition of commercial digitisation systems.

Meanwhile, regarding Matroska and FFV1, a user perspective is presented in Mike Casey's very helpful paper, Encoding and Wrapper Decisions and Implementation for Video Preservation Master Files, Indiana University (2017).  Mike's white paper calls attention to the value of the open-format approach and the risk-avoidance that the university's Media Digitization and Preservation Initiative (MDPI) saw in the adoption of this format combination.  The Indiana University project post-dated the MXF adoptions cited in the preceding paragraph, beginning with an early phase in 2011-12, using a version of the MPEG-2 lossy encoding format.  The MDPI team revisited format selection in 2015 as the refinement and IETF standardizing of Matroska and FFV1 was moving into high gear, and they embraced that format combination.

All of us look forward to hearing from adopters of the MXF and Matroska/FFV1 format options.  Our collective experience during the near term will improve our understanding of each format's pluses and minuses.

Comments on this blog?  Please use the form below to add your comments, which will be queued for approval. IASA members can log in and publish comments immediately.