[Specification (Published)] AMWA AS-11 X7
MXF Program Contribution - SD

AS-11: Media Contribution File Formats

The AMWA AS-11 Specifications define constrained media file formats for the delivery of finished media assets to a broadcaster or publisher. Each Specification is developed for a particular business purpose.

Purpose of the AS-11 X7 Specification

Aims

This Specification aims to define a file format for the delivery of finished SD TV Programmes with intra-coded ("I-frame") picture essence. It aims to define:

• a vendor-neutral and broadcaster-neutral package, using open technologies for delivery of finished programming from program producers and program distributors to broadcast stations
• a package that is sufficiently simple so as to limit the scope for interoperability problems
• a self-contained & play-out ready package

Some notes on practical use

• The content may be delivered at the broadcast bit-rate, picture format and aspect ratio, or it may be transcoded at the broadcast station to the bit-rates and formats required for particular broadcast channels. Similar transcoding may be applied to audio and captions; additionally, specific audio and caption tracks may be selected for different broadcast channels.
• The content may be pre-packaged for broadcast without further changes or it may be segmented for ease of insertion or replacement of interstitials.
• There may be more than one package per programme.
• The package may contain some pre and post roll content not for transmission.

Understanding the Specification Blocks Tree

The Rules-Based Specification Framework

This Specification has been written using a 'Rules-based Specification Framework'. In this framework, each 'constraint' or 'rule' is expressed as a 'Component' which can be unambiguously identified by its ID (the Component ID is a web address / URL; there need not be any content available at this web address). These Components assemble into 'networks' or 'webs' to form complete Specifications, with many Components being re-used across a number of Specifications. Through this approach machine processable Specifications are developed which are less ambiguous and easier to implement and test. To read a more detailed introduction to the Rules-based Specification Framework refer to Rules-Based Specifications: Modelling and Processing.

• Blocks (B) are the fundamental 'building bricks' of a Specification -- they provide its structure.
• A Block can either link to Artefacts (A) that it 'owns' or link to other Blocks.
• Artefacts provide the real content of a Specification. They may contain textual statements, code excerpts, or tables, for example.
• Artefacts often refer to Terms (T) and References (R) as well as Blocks.
• Blocks are sometimes described by Notes (N).
• There are two special types of Block which allow the value of one Block to be set by another Block:
  • Parameter Key Block (K) -- this is a Block whose value must be set elsewhere in the Specification (it effectively defines a "variable" or an "argument").
  • Parameter Value Block (V) -- this is a Block which sets the value of a specific Parameter Key Block.

In this document the network of Blocks (and other Components) that form the Specification are shown as a 'tree': the Specification Blocks Tree. The letters in brackets above are used in the tree to identify the different kinds of Component.

Conformance

An implementation complies with this Specification if it complies with the Components from which it is constructed, as shown in the Specification Blocks Tree, subject to the following provisions:

• An implementation complies with a Block if it complies with all of the normative Components from which it is constructed. "Informative" items (as defined below) do not have to be complied with.
• "Note" Components are considered "informative". All other Components are considered "normative" unless otherwise noted.
• Compliance with some Blocks is not mandatory. Such Blocks are marked with an alternative "conformance" state (such as "optional" or "recommended").
• The name / title of a Component is considered "informative".
• Prose Artefacts are written as statements of fact. An implementation complies with one of these Artefacts if the stated fact is True for the implementation.
• Other Artefacts are "data files" (such as SMPTE Metadata Registers XML files or XML Schema files). Some of these may be partially rendered below. An implementation must always fully comply with these data files -- links are provided to such data files in the Specification Blocks Tree.
• Note that an Artefact does not always make sense on its own: all of the Artefacts contained within a Block need to be read (in order) to understand the Block fully and correctly.