New delivery channels such as IPTV and mobile are creating opportunities for broadcasters and content owners to reach consumers with new and existing content. How can technology help to ensure that this is done cost-effectively, both in the rollout stages and in the mature market phases of these new channels? This article will cover the basics of mastering and repurposing and will look at issues that affect reusability of content, picture quality and the consumer's experience of these new channels.
So many versions …
The business of broadcasting is changing. Gone are the traditional requirements of creating a single version of a TV program for airing on a prime channel. Today's broadcaster needs to consider the distribution of a program, not only for its first showing on TV, but also for secondary showings delivered via terrestrial, satellite, cable, IPTV, Web, mobile and even podcast.
It would be nice to think that each of these versions would generate equal revenue from a new group of consumers, but the reality is that these new channels require stringent cost-controlled delivery if they are to turn into a profitable long-term business.
One way for broadcasters to do this is to rely on IT and automation. Moving toward an operational scenario where minor adjustments can be made to a “master” of the asset to produce the different revenue-generating distribution versions seems like an obvious way to go. In practice, however, incompatible file formats and compression issues make it a difficult goal to achieve.
At present, many IT-based systems use a file format/compression system optimized for their particular product or application area. Playout servers and editing engines are often battling different ends of the spectra for usability, file size and editability, turning interoperability into an art form.
End users designing a facility often choose operational file format/compression systems based on what they already have and their current needs. The end result is that facilities have different native file formats in operational use. Over time, this means vendors will have to implement all the file formats in order to interoperate properly. This requires massive engineering overhead — a cost passed on to the end user.
The MXF file format was designed to take into account this precise scenario. So, why can't we buy a solution off the shelf? Why isn't MXF the overwhelming native file format of choice for building a broadcast facility that addresses not only broadcast but IPTV, mobile and other delivery media?
The answer is that the design scope of MXF is broad. To use MXF as a master file format for cost-effective IT-based content delivery, we need to manage MXF's complexity. This involves defining rules for operational use of the files and defining metadata for indicating language variants. And it requires vendors working together to achieve good interoperability.
The MXF master file
The goal of using an MXF master file is to create a group of files structure manageable at the MXF level. This structure allows all assets to be handled in the same way regardless of whether they are MPEG-2 master videos for playout or edited versions for repurposing to mobile phones.
Essence files are referenced by an MXF master file that links them all together and synchronizes their audio, video and data components. All files must appear to be completely valid MXF files and be playable at all times, including during capture/ingest and while being updated. This is important in a shared storage environment in which there may be several read processes operating on the file simultaneously.
Figure 1 shows the basic structure, for which:
- the program version file (Example.mxf in Figure 1) references the program components;
- each program component file (i.e. the essence) contains only a single sort of essence — be it video, audio or VBI;
- each program component contains MXF metadata that describes what has actually been stored (e.g., 50Mb I-frame SD video at 59.94fps);
- all program component files are standard OP1a MXF and can be played by any player;
- each program version file references the stored program component to indicate the start and end points of the playout; and
- the program version file is standard MXF, and no new standards are needed to describe this structure.
Table 1 lists the various types of files required when building a large facility with MXF, with their definitions.
Table 1. Definitions of MXF file types Application Structure Operational Pattern Program component MXF essence file OP1a mono essence with partitions Simple program version Synchronized essence files OP1b with external essence Complex program version Synchronized essence files OP3b with external essence Program inventory File containing several versions OP3c aggregation of versions with external essence
The MXF master format enables the ability to master content once and then repurpose it to many out-put formats. The format uses only standardized elements from the SMPTE MXF specifications and recommends restrictions on MXF encoder behavior to enhance interoperability between decoders, as well as meet the requirements of managing assets in a consistent fashion irrespective of the compression formats or image resolutions being used.
Interoperability
The goal of the MXF master format is to create cost-effective, streamlined workflows based on open standards. The following is an example of the benefits offered by this approach, in which use of the MXF master format allows the content owner to answer this question: How do I capture an HD signal into an MPEG-2 file and then create a DNxHD submaster and an H.264 submaster, all with identical ANC data?
One of the issues with processing ANC data in files is that there is little common practice between vendors. Furthermore, the ANC, as well as VBI, data is often stored in a proprietary fashion on a device. Moving the ANC data from one domain to another often requires custom software creation and the associated testing of that software. In the MXF master format, ANC and VBI data is stored as another program component and handled at the MXF level.
Figure 2 shows the addition of the ANC or VBI program component. The program version file (Example.mxf) is updated to synchronize the added component. Having added the ANC or VBI program component, it is now in a standard MXF form. This means that an application that needs to convert EIA-708 captions into EIA-608 captions, for example, can read the standardized MXF program component without having to understand how the data was embedded in the video component file.
Reusability
Figure 3 shows the creation of language variants of an asset. The program inventory metadata file can be thought of as a number of individual program version files referencing the same video essence and the individual language variants of the file. Tagging the multiple language variants is achieved using standard MXF tools as explained later.
In many circumstances, not just the audio track of a file changes between language variants. Often the title sequences and the credit sequence need to be altered or extended. The MXF master file provides a complex program version that is able to sequence together a number of program components to achieve the reuse desired. The header file that sequences together several AV essence files is shown in Figure 4.
Finally, management of all the versions can be enhanced by using an inventory MXF file that binds together all the different atomic essence files. The header file can be arranged to show the relative synchronization between all the atoms. The file may also be used to bind together the different MXF essence identifiers (UMIDs) as an aid to tracking the content.
Identification of foreign-language variants
Versioning is widely used to produce assets with multiple language tracks. To keep track of which language an audio program component corresponds to, the language should be tagged in the file package of the program component and in the material package of any program referencing the atom.
Using standardized metadata (RFC 4646) and a standardized metadata container (SMPTE 380M, a descriptive metadata scheme also known as DMS-1), we can add language-tagging metadata that can be widely understood with little extra work required by vendors. (See Figure 5.)
The tagging is accomplished using the DMS-1 production framework. A descriptive metadata (DM) track is added to the package in the MXF file. The DM track has a text language code that is always set to “en-US” to indicate that annotation within the file is always in the English language as spoken in the United States. The spoken language property is used to indicate the actual language that is spoken in the audio track with “en-GB,” for example, indicating the language is English as spoken in Great Britain.
Language annotation is, however, highly business-sensitive. There may well be a desire to indicate within the file that it is a version of the English soundtrack that has been checked and cleared to ensure that there is no profanity so that it can be aired during the daytime. RFC 4644 provides extension mechanisms to allow the syntax of these business-specific extensions to be standardized.
Playout server compatibility
The MXF master file has been designed with input from playout server vendors such as Omneon. The integration of appropriate file conversion applications into the system makes it possible to optimize the variant of MXF at the appropriate location in a facility.
For example, complex program versions on nearline storage can easily be edited and manipulated. When the file is required on a playout server, issues such as channel count, delete tracking and program component complexity become important. File conversion engines can be used to convert a complex program version into a simple program version that is optimized for the playout function.
Bandwidth saving
A component-based file format can be used effectively to reduce storage and bandwidth requirements in a facility. In Figure 6, we restore an interleaved file from an archive, add an audio track to it, place it on a playout server and broadcast it on some channel. If we want to archive this new audio component, then we have to copy the entire interleaved video and audio and add it to the archive.
Using the MXF master file for the same operation results in identical playout workflow. The difference is in the recovery of the new material added. (See Figure 7.) All that is required is copying the audio component file, resulting in a savings of bandwidth and storage. It is also likely to result in a shorter time to complete the operation and a higher chance of interoperability given that all files in the system follow the same open standard.
Business continuity and disaster recovery
A feature of MXF files is that they contain a hierarchy of content identifiers. MXF-compliant devices are required to maintain the integrity of the links between stored content and played content. This means that they must have a valid source reference chain.
Well-behaved MXF applications also preserve the history of previous generations of the file's contents by extending the source reference chain with historical information. When a valid source reference chain is coupled with the use of the MXF master file, real benefits occur.
First, by using program component files instead of an interleaved file format when storing the master on high-capacity tape (such as LTO), new synchronized essence tracks can be appended to the tape archive instead of requiring the rewriting of large interleaved files. Appending brings a speed benefit and allows updating of the asset using standard file commands rather than requiring custom software to be written.
Second, by using MXF's source reference chain, the tape archive becomes a self-describing link of the genealogy of the asset. The tape archive then allows the automation of the ingest and reconciliation of the assets in a structured and standardized way.
Putting it into practice
Far from being a paper-based exercise, the MXF master file format is being documented, debugged and implemented to prove the concept. A live demonstration is planned for NAB2007. It will include interoperable equipment from several vendors, showing the business value of an interoperable open standard.
Creation of multiple versions of content for diverse distribution platforms such as IPTV and mobile devices can be performed automatically and cost-effectively using MXF. Playout servers and file conversion software exist to use MXF and create revenue-generating files for new media distribution.
Bruce Devlin is vice president of technology for Snell & Wilcox in the UK.
