The evolution of MXF
May 1, 2010 12:00 PM, By Neil Dunstan
The Material eXchange Format offers efficiencies.
Figure 1. The AS-03 fi le is used to deliver fi nished programs.
Select figure to enlarge.
The Material eXchange Format (MXF) was conceived as a wrapper for media content that allows flexibility in file formats. Its adoption as a file format by both manufacturers and media companies delivers the potential for significant business efficiencies. This is possible from two main areas:
In system architecture where manufacturers' products interconnect reliably, enabling a degree of integration that was difficult to achieve before file-based workflows.
In the efficient use of staff resources, as more processes can now be automated, leaving the skilled people to carry out the tasks that really need human intervention.
Application specifications
Since broadcasting began, there has always been a concern that one manufacturer's product would not be compatible with another's. This worry about interoperability has been a potential barrier to the widespread, large-scale adoption of file-based workflows.
As a result, media companies and vendors joined to form the Advanced Media Workflow Association (AMWA) in order to draw up application specifications (AS) as the basis for simple, easy interoperability.
Figure 2. The structure of an AS-02 fi le showing
the version fi les and the essence within the
media folder
Select figure to enlarge.
And although the specification for MXF allows it to be used anywhere in the program path, it became clear from a number of media companies that there were some areas where it could immediately support their changing business requirements.
The application specifications are not specific to one vendor. They define a set of constraints on how the file is constructed to match the operational and technical requirements at a particular point in the workflow.
This tailors the use of the AS to a specific requirement. The purpose of the constraints is to minimize the number of options that must be considered by implementers of individual devices within the system. This helps both vendors and system architects, and increases the reliability and interoperability of the overall system.
This is ideal for an industry where every media company operates differently and where contributions to the creation of a program now come from many companies, often physically distant from the broadcaster.
If even tighter constraints are required for, say, a specific broadcaster's use or a particular program genre or distribution channel, these can be defined as shims. (Note the comparison with mechanical design, where a thin shim is used to make something fit exactly.) For example, there is a shim for the PBS application of AS-03 that is used for program delivery to its member stations across the United States.
To ensure widespread support across the industry, AMWA works in conjunction with both SMPTE and the EBU. Here are practical examples of two such specifications.
Delivery of finished content
An AS-03 file is always a single file for a single program. (See Figure 1.) The content of these files is not intended for further processing before delivery to the consumer but for direct playout from any server. The file contains a finished program or program segment with its associated metadata and typically includes video, audio and subtitles plus the technical and descriptive metadata for aspect ratio or parental control switching.
Program versioning
For many years, we have seen a steady exploration of new distribution channels and the financial exploitation of archive material. Upstream from the playout process is an increasing need to create multiple versions of a program. It is not unusual for a program to have multiple versions of:
Video (standard and high definition for television and lower resolution for online and mobile consumption);
Audio (stereo and Dolby 5.1 in any number of languages);
Subtitles (potentially as many as the number of audio languages);
Metadata used for automated control of the workflow or distribution; and
Metadata used to describe the material for later reuse.
To satisfy this demanding business and operational requirement, AS-02 was developed. (See Figure 2 on page 16.) Often the translation and dubbing service for the audio and multilanguage subtitling of material for international distribution is provided by the country destined to consume the content. However, the playout is usually from a centralized facility, so the management and movement of the material is a complicated task, requiring everyone to work with the same standards.
How does a complicated system allow cost savings to be achieved? Traditionally, multiple versions of a program require the video material to be duplicated for each version. This creates cost through the effort required for dubbing and the extra space used on servers for storage, plus the fact that any transfer operation has the potential for technical or operational errors to occur. Use of AS-02 allows just one copy of each piece of material to be stored, along with data that describes the elements making up each of the final versions. In Figure 1, the asset “Alice” contains one of multiple MXF files in the root folder Alice, each referencing the relevant essence components in the media folder. This ensures that each version is correct and avoids unnecessary labor and storage costs.
Multilanguage environment
Where one piece of video content has associated audio tracks for international and multicultural distribution, effective language tagging of the audio is vital. AS-04 has been defined to satisfy this requirement and integrates with the basic AS-02 specification.
Continue to next page
| Want to use this article? Click here for options! |  |
