[Specification (Published)] AMWA AS-11 X7
MXF Program Contribution - SD
About this web page
This web page is the principal rendering / view of the AMWA AS-11 X7 Specification.
Full details of all the Components (Blocks, Notes, and the others) that form this Rules-based Specification are either shown directly on the current web page or are included in the "specification_data_files" directory that accompanies the page (with explicit links from the current page).
| Important links | |
|---|---|
| Specification Repository on GitHub | This repository is where the entire Specification (including this file and alternative renderings / views of the Specification) is stored and version controlled |
| List of Releases | Milestones marking significant points in the development of the Specification |
| Specifications Page on the AMWA Website | The home of Specifications on the AMWA website |
| Development and Implementation Resources | Provides resources such as Specification issue tracking, MXF sample files, and tools |
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.
The Specification Blocks Tree
The following icons are used in the Specification Blocks Tree:
Block- Its meaning is defined by its contents, which can be Artefacts or other Blocks.
Parameter Key- A Block whose value must be set elsewhere in the Specification (it effectively declares a "variable" or an "argument").
Parameter Value- A Block which sets the value of a specific Parameter Key Block.
Note- This provides informative guidance on the implementation or application of a Block.
Artefact- A statement or a data file within a Block.
Note Artefact- A statement or a data file within a Note.
- An icon with a solid fill denotes constraints that are mandatory.
- An icon with an outline style denotes constraints that are not mandatory.
- Metadata about a Rules-based Specification Component.
-
File Format
-
Component metadata
-
Core MXF constraints
-
Component metadata
-
MXF File Format
-
Component metadata
-
The file conforms to SMPTE ST 377:2004.
-
Later versions of MXF
-
Component metadata
-
This does not prohibit the use of MXF version 1.3 (SMPTE ST 377-1:2011) for SD files. SMPTE encourages users to apply the most recent edition of standards where possible.
-
-
-
Operational pattern 1a
-
Component metadata
-
The file conforms to SMPTE ST 378:2004.
-
Implementation Notes
-
Component metadata
-
The file must be labelled as OP1a in the Operational Pattern property of all Partition Packs and the Preface Set, as required by SMPTE ST 377-1:2011 in Section 7.1 and Annex A, respectively.
-
-
-
Closed Complete Header
-
Component metadata
-
The Header Partition is "Closed" and "Complete".
-
Implementation Notes
-
Component metadata
-
Byte 15 of the Header Partition Pack Key must be set to 04h and all Header Metadata must have correct values. Hence 'Distinguished Values' cannot be used for 'Best Effort' properties. See Section 6.2.3 of SMPTE ST 377-1:2011 for a full explanation.
-
-
-
Generic Container
-
Component metadata
-
The file uses the Generic Container.
-
-
Internal Essence
-
Component metadata
-
The Generic Container is internal to the file.
-
-
Strict Frame Wrapping
-
Component metadata
-
The Generic Container uses Frame Wrapping.
-
If the Generic Container contains Picture Essence then the related Edit Unit duration is equal to the duration of a video frame of the Picture Essence.
-
Implementation Notes
-
Component metadata
-
For example, this means that if the Picture Essence is field-encoded then each Edit Unit contains the data assosiated with both of the video fields for a video frame.
-
-
-
One-to-one Track mapping
-
Component metadata
-
Each Essence Track in the Top-Level File Package is referenced by exactly one Essence Track in the Material Package.
-
No division/combination of Audio Channels between Sound Tracks
-
Component metadata
-
This prohibits:
- the mapping of audio channels from a multi-channel Sound Track in a Source Package to single-channel Sound Tracks in the Material Package
- the mapping of audio channels from single-channel Sound Tracks in a Source Package to multi-channel Sound Tracks in the Material Package
which is specified in Annex E of SMPTE ST 382:2007.
-
-
-
-
Header Metadata KLV Fill (Recommended)
-
Component metadata
-
When first created, the file includes a KLV Fill item of at least 4 MB in total length following the Header Metadata.
-
Implementation Notes
-
Component metadata
-
The "total length" is of the entire item and includes the length of the Key and Length fields.
The extra space afforded by the KLV Fill allows Header Metadata to be edited and added to without rewriting the entire file.
-
-
Definition of megabyte
-
Component metadata
-
The unit symbol "MB" refers to a megabyte, which is 1 000 000 bytes.
-
-
-
MXF Indexing and Partitioning strategy for CBE Essence
-
Component metadata
-
Index precedes Essence
-
Component metadata
-
The file contains a complete Index Table before the Essence.
-
-
Index all Essence
-
Component metadata
-
The Index Table indexes every Edit Unit of every Essence Element in the file.
-
-
Single Essence Partition
-
Component metadata
-
The Generic Container is entirely contained in exactly one Partition.
-
-
Indexing and Partitions
-
Component metadata
-
It's generally considered good MXF practice to have one 'thing' per Partition, so you'd have separate Partitions for Header Metadata, Essence, and Index Tables. This isn't a requirement but following best practice is encouraged.
The Index Table could be placed in the Header Partition, its own Body Partition or in a Body Partition with the Essence. Indeed it could be distributed across all three of these locations. Decoders need to be able to cope with all of these posibilities.
-
-
-
ST 386 with D-10 625i25 at 50 Mbps
-
Component metadata
-
The file conforms to SMPTE ST 386:2004 where the Picture Essence operates at "50 Mbit/s" using a "625/50 system".
-
Implementation Notes
-
Component metadata
-
All aspects of SMPTE ST 386:2004 must be followed. In addition to the mapping of the AES3 Sound Essence and D-10 Picture Essence, it also covers other things such as Index Tables and KAG size.
The KLV Alignment Grid of any Partition containing an Essence Container must be 512.
SMPTE ST 386:2004 specifies that there is exactly one Sound Track in each of the Material Package and Top-Level File Package.
D-10 Picture Essence
While not strictly specified, the Picture Essence has 608 lines (576 of active picture plus 32 of vertical interval), as is conventional for D-10 pictures and which is alluded to in SMPTE ST 365:2001.
The constraints on Picture Essence encoding here imply a "level" of "main".
Standard Definition content can have an aspect ratio of 16/9 or 4/3.
-
-
-
Uncompressed 24-bit PCM audio at 48 kHz
-
Component metadata
-
For each Audio Channel the Sound Essence is "uncompressed PCM audio data" per SMPTE ST 382:2007, sampled at 48 kHz with 24 bits per sample.
-
Implementation Notes
-
Component metadata
-
As per Section 6 of SMPTE ST 382:2007 samples are stored as little-endian integers.
-
-
-
Embedded XML Documents
-
Component metadata
-
An XML document defined by XML DM for Programmes is embedded in the file using XML Document in Header Metadata Carriage.
-
XML DM for Programmes
-
Component metadata
-
The namespace of the document's root element is Programmes Descriptive Metadata; the name of the document's root element is "Programmes_DM"; the Media type (MIME type) for the document is "application/xml"
-
Programmes Descriptive Metadata
-
Component metadata
-
XML Schema
View the HTML Documentation for the XML Schema
View the primary XML Schema file:
View the imported XML Schema file(s):
- specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts/import/DM_Identification.xsd
- specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts/import/DM_Programmes_DomainSpecific.xsd
- specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts/import/DM_InVisionAccessServices.xsd
- specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts/import/DM_ContentDetails.xsd
- specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts/import/DM_Common.xsd
- specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts/import/DM_Extras.xsd
-
-
-
-
XML Document in Header Metadata Carriage
-
Component metadata
-
The XML document is a complete XML document (with a single root element) that is UTF-8 encoded without a "Byte-Order Mark" (BOM).
-
The XML document is carried in the Header Metadata according to SMPTE RP 2057:2011.
-
The instance of "Text-Based DM Framework" is strongly referenced from a Constrained Static DM Track.
-
Constrained Static DM Track
-
Component metadata
-
A Constrained Static DM Track is a Static Track (DM) in the Material Package that contains a Sequence, which contains exactly one DM Segment, which strongly references an instance of a DM Framework.
-
Track Name
-
Component metadata
-
The "Track Name" property of an Constrained Static DM Track does not identify the DM Scheme whose DM Framework it references. In the absence of other requirements for "Track Name", it is suggested that files use a value corresponding to the DM Scheme used in the track, e.g. "AS_11_Core", "AS_11_UKDPP".
-
-
-
-
The XML document is carried in the "UTF-8 Text Data" property of the "UTF-8 Text-based Set".
-
In the "UTF-8 Text-based Set" the property "Text-based Metadata Payload Scheme ID" has the value of DM_XML_Document.
-
DM_XML_Document
-
Component metadata
-
SMPTE Metadata Registers – Labels
Kind UL Symbol Definition LEAF urn:smpte:ul:060e2b34.04010101.0d010801.04010000 DM_XML_Document Descriptive Metadata XML Document in Header Metadata View the SMPTE Metadata Registers XML file(s):
-
SMPTE Registers Node: MetadataPayloadSchemes
-
Component metadata
-
SMPTE Metadata Registers – Labels
Kind UL Symbol Definition NODE urn:smpte:ul:060e2b34.04010101.0d010801.04000000 MetadataPayloadSchemes View the SMPTE Metadata Registers XML file(s):
-
-
-
-
In the "UTF-8 Text-based Set" the property "Text Data Description" is present and has a value equal to the namespace of the root element of the XML document.
-
2-byte Local Length Encoding is used for both the "Text-Based DM Framework" and the "UTF-8 Text-based Set".
-
ST 2057 Implementation Notes
-
Component metadata
-
XML Document size limits
The constraints mean that Byte 6 of the two set keys will be 53h. The amount of text data must be equal to or less than 65535 bytes.
Amendment
A crucial amendment to ST 2057 exists and must be read carefully -- it changes the ULs of various keys used in the Standard.
-
-
-
-
The "UTF-8 Text-based Set" that carries this embedded XML document is uniquely identified within the
sets_in_scopeby the value of its "Text Data Description" property; wheresets_in_scopeconsists of all the instances of "Text-based Object" (as defined by SMPTE RP 2057:2011) present in the Material Package that have a value of DM_XML_Document for the "Text-based Metadata Payload Scheme ID" property.-
DM_XML_Document
-
Component metadata
-
SMPTE Metadata Registers – Labels
Kind UL Symbol Definition LEAF urn:smpte:ul:060e2b34.04010101.0d010801.04010000 DM_XML_Document Descriptive Metadata XML Document in Header Metadata View the SMPTE Metadata Registers XML file(s):
-
SMPTE Registers Node: MetadataPayloadSchemes
-
Component metadata
-
SMPTE Metadata Registers – Labels
Kind UL Symbol Definition NODE urn:smpte:ul:060e2b34.04010101.0d010801.04000000 MetadataPayloadSchemes View the SMPTE Metadata Registers XML file(s):
-
-
-
-
Other Text/XML Documents can also be Embedded
-
Component metadata
-
This Block does not prohibit other text documents (XML or otherwise) from also being embedded in the MXF file. This could be useful because it allows custom XML documents also to be carried along with the mandated XML document(s).
Note that the stated constraints help readers in identifying the mandated XML document(s); if a device examines all sets / objects that meet all of the following criteria:
- it is an instance of a "Text-based Object" (so it is a "Generic Stream Text-based Set", "UTF-8 Text-based Set" or "UTF-16 Text-based Set")
- it is in the Material Package
- the "Text-based Metadata Payload Scheme ID" property has the specified value
then the set / object containing a specific mandated XML document can be uniquely identified by the value of its "Text Data Description" property (this property contains the namespace of the root element of the XML document).
-
-
-
AS-11 Segmentation DM (Descriptive Metadata)
-
Component metadata
-
The file contains exactly one Program Segmentation Track.
-
Program Segmentation Track
-
Component metadata
-
A Program Segmentation Track is a Timeline Track that contains a Sequence that is composed of zero or more Filler objects and one or more DM Segment objects.
-
Each DM Segment object in the Program Segmentation Track represents, and aligns with, a region of program content in the Source Essence.
-
Each Filler object in the Program Segmentation Track represents, and aligns with, a region of non-program content in the Source Essence.
-
Track Name
-
Component metadata
-
The "Track Name" property of the Program Segmentation Track does not identify the segmentation metadata scheme. In the absence of other requirements for "Track Name", it is suggested that files use a value corresponding to the DM Scheme used in the track, e.g. "AS_11_Segmentation".
-
-
Determining SOM and EOM
-
Component metadata
-
The start and end timecodes for program regions, commonly referred to as "start of material" (som) and "end of material" (eom), can be determined based on the location of DM Segment objects on the Program Segmentation Track relative to the adjacent Timecode Track in the Material Package that contains the Program Segmentation Track.
-
-
Non-Programme Content
-
Component metadata
-
Examples of non-programme content include: black, ident, clock.
-
-
-
-
This Track is in the Material Package.
-
Each DM Segment object in the Track strongly references an instance of DM_AS_11_Segmentation.
-
DM_AS_11_Segmentation
-
Component metadata
-
This DM Scheme is identified by DM_AS_11_Segmentation (the DM Scheme Label) and has the following members: DM_AS_11_Segmentation_Framework (the DM Framework).
-
DM_AS_11_Segmentation
-
Component metadata
-
SMPTE Metadata Registers – Labels
Kind UL Symbol Definition LEAF urn:smpte:ul:060e2b34.04010101.0d010701.0b020000 DM_AS_11_Segmentation AS-11 segmentation metadata scheme View the SMPTE Metadata Registers XML file(s):
-
-
DM_AS_11_Segmentation_Framework
-
Component metadata
-
Framework / Group
UL: urn:smpte:ul:060e2b34.027f0101.0d010701.0b020100
Symbol: DM_AS_11_Segmentation_Framework
Properties / Elements in the Framework:
UL Symbol Definition Type Symbol Is Optional Restrictions urn:smpte:ul:060e2b34.01010101.0d010701.0b020101 AS_11_Part_Number A number that both: uniquely identifies the part / segment within the programme; and identifies the position of the part / segment within the programme. UInt16 false urn:smpte:ul:060e2b34.01010101.0d010701.0b020102 AS_11_Part_Total The count of parts / segments in the entire programme. UInt16 false View the SMPTE Metadata Registers XML file(s):
- specification_data_files/www.amwa.tv_c0f7b64/block/505F/artefacts/Groups.xml
- specification_data_files/www.amwa.tv_c0f7b64/block/505F/artefacts/Elements.xml
- specification_data_files/www.amwa.tv_c0f7b64/block/505F/artefacts/Types.xml
-
-
-
-
-
Implementation Notes
-
Component metadata
-
The Track can be identified by an MXF reader by the presence of DM Segment objects that each strongly reference an instance of the "DM_AS_11_Segmentation_Framework" DM Framework.
-
As the Track is in the Material Package, it is necessarily full from start to finish and is the same length as all other Timeline Tracks in the Material Package.
-
-
Repetition of Header Metadata
-
Component metadata
-
Repetition of Header Metadata in the Footer Partition is not considered to be another instance of any of the components of that Header Metadata.
-
-
-
Specification Identification
-
Component metadata
-
The Specification_Identifiers Element is present in the Preface of the Header Partition.
-
Specification_Identifiers
-
Component metadata
-
SMPTE Metadata Registers – Elements
Kind UL Symbol Definition Type Symbol Restrictions LEAF urn:smpte:ul:060e2b34.01010101.0d010801.01010000 Specification_Identifiers A set of AUIDs where each AUID identifies a "file format" "Block" to which the MXF file conforms. A "file format" "Block" is a "Block" (a Rules Framework Component) that is usually at (or close to) the root of a Rules-based Specification. AUIDSet View the SMPTE Metadata Registers XML file(s):
- specification_data_files/www.amwa.tv_c0f7b64/block/SpecID/artefacts/Elements.xml
- specification_data_files/www.amwa.tv_c0f7b64/block/SpecID/artefacts/Types.xml
-
SMPTE Registers Node: Specification_Identification (Elements Register)
-
Component metadata
-
SMPTE Metadata Registers – Elements
Kind UL Symbol Definition Type Symbol Restrictions NODE urn:smpte:ul:060e2b34.01010101.0d010801.01000000 Specification_Identification View the SMPTE Metadata Registers XML file(s):
-
-
-
-
The value of this Element includes the Label Blocks_FF_7.
-
Blocks_FF_7
-
Component metadata
-
SMPTE Metadata Registers – Labels
Kind UL Symbol Definition LEAF urn:smpte:ul:060e2b34.04010101.0d010801.05080000 Blocks_FF_7 Blocks File Format 7 View the SMPTE Metadata Registers XML file(s):
-
-
-
-
Timecode constraints
-
Component metadata
-
Timecode Track Presence
-
Component metadata
-
The Material Package contains exactly one Timecode Track.
-
Implementation Notes
-
Component metadata
-
This Timecode Track provides "Synthetic Timecode" because its Timecode is "generated" from a single "Start Timecode" value that is associated with the beginning of the Material Package. This means that the Timecode is necessarily continuous throughout the entire playback of the MXF file.
-
-
-
Constrained Timecode Track in Material Package
-
Component metadata
-
The Timecode Track in the Material Package is a Constrained Timecode Track.
-
Constrained Timecode Track
-
Component metadata
-
The value of the "Edit Rate" property of this Timecode Track is the same as the value of the "Edit Rate" property of the Picture Track in the same Package.
-
There is exactly one Timecode Component in this Timecode Track.
-
The value of the "Rounded Timecode Base" property of the Timecode Component is the "Edit Rate" of this Timecode Track rounded to the nearest integer.
-
-
-
-
Timecode mode signalling
-
Component metadata
-
The value of the "Drop Frame" property of the Timecode Component in the Timecode Track in the Material Package is "False" (indicating non-drop frame timecode is in use) except in any of the following scenarios (in which case it is "True", indicating drop frame timecode is in use):
- The "Rounded Timecode Base" property of the Timecode Component is
60and the "Edit Rate" of the Timecode Track is mathematically equal to60000/1001 - The "Rounded Timecode Base" property of the Timecode Component is
30and the "Edit Rate" of the Timecode Track is mathematically equal to30000/1001
- The "Rounded Timecode Base" property of the Timecode Component is
-
Rational Numbers
-
Component metadata
-
Care must be taken when dealing with numbers expressed as a ratio of two integers ("rationals"). They are often used to represent temporal rates or image aspect ratios.
When making comparisons of these values, it is insufficient to simply compare each of the numerators and each of the denominators. For example,
7/5is mathematically equal to14/10.
-
-
Implementation Notes
-
Component metadata
-
Note that for an "Edit Rate" of 24000/1001 the "Drop Frame" property will be "False" because drop frame timecode is not applicable to this rate.
-
-
-
Timecode Track Precedence
-
Component metadata
-
The Timecode Track in the Material Package defines the authoritative program timecode.
-
Implementation Notes
-
Component metadata
-
The Timecode defined by the Timecode Track in the Material Package must be used by all the components of a system that handles the file. Other Timecodes could be present in the file but these are not authoritative -- these other Timecodes could be used by certain systems for very specialist purposes (such as keeping track of where each frame of content originated from) but they must never be used as the authoritative / principal Timecode for the content.
-
-
-
-
Miscellaneous Content Constraints
-
Component metadata
-
AFD present
-
Component metadata
-
The "Active Format Descriptor" property of the Picture Essence Descriptor is present in the file.
-
Implementation Notes
-
Component metadata
-
Section G.2.5 of SMPTE ST 377-1:2011 describes compliant encoder and decoder behavior with respect to SMPTE ST 2016-1:2009.
-
-
-
AFD 9 10 14
-
Component metadata
-
The 4-bit AFD encoded in the "Active Format Descriptor" property of the Picture Essence Descriptor is one of the following decimal values: 9 or 10 or 14.
-
Implementation Notes
-
Component metadata
-
Section G.2.5 of SMPTE ST 377-1:2011 requires that the value of the "Active Format Descriptor" property be constant for the duration of the associated Picture Track.
The AFD (as it is used here, where only a very restricted set of values are permitted) can be considered as telling the decoder what video transformations it can reasonably make when displaying the video. For example when displaying the video on a "problematic" screen the decoder could wish to "zoom and crop" or "pillarbox" or "letterbox" the video as appropriate (where a "problematic" screen could be one where the dimensions of the screen mean that if the video is displayed full-screen it does not have the stated "aspect ratio").
-
-
-
4 audio channels
-
Component metadata
-
Only the channels in the 8-channel AES3 element with a "channel number" of 1, 2, 3 or 4 are valid.
-
-
Audio Channel Layout
-
Component metadata
-
The audio channel with the "channel number" of 1 is the Left channel of Stereo Main Programme.
The audio channel with the "channel number" of 2 is the Right channel of Stereo Main Programme.
-
-
Implementation Notes
-
Component metadata
-
Use of Audio Channels 3 & 4
This Block imposes no restrictions on the contents of the audio channels with "channel number" 3 and 4. There is, however, no means to indicate (within the file) what they do contain.
-
-
-
Table of Terms
| Term | Explanation |
|---|---|
| 2-byte Local Length Encoding | A syntax encoding for "Local Sets" that uses 2-byte Tags and 2-byte Lengths. Defined By: SMPTE ST 377-1
|
| 8-channel AES3 element | A way of multiplexing up to eight channels of AES3 audio data. Defined By: SMPTE ST 331
|
| Audio Channel | A distinct collection of sequenced audio samples that are intended for delivery to a single loudspeaker or other reproduction device. Defined By: SMPTE ST 377-4
|
| Descriptive Metadata | Generic term used for descriptive data whose purpose is to describe Essence data. Defined By: SMPTE ST 377-1
|
| DM Framework | A Descriptive Metadata Class that is a Subclass of Descriptive Framework. Defined By: SMPTE ST 377-1
|
| DM Scheme | A mechanism for defining collections of Descriptive Metadata. Defined By: SMPTE ST 377-1
|
| DM Scheme Label | An identifier for a DM Scheme. It is stored in an MXF file's Preface::DMSchemes property to signify the use of that DM Scheme in the file. Defined By: SMPTE ST 377-1
|
| DM Segment | An MXF structure used to generically contain Descriptive Metadata on a Track. Defined By: SMPTE ST 377-1
|
| Edit Unit | A temporal division of a Track. Defined By: SMPTE ST 377-1
|
| Essence | A bitstream comprising picture, sound or data. Defined By: SMPTE ST 377-1
|
| Essence Element | The entire essence stream of a single Track. Defined By: SMPTE ST 379-2
|
| Essence Track | A type of Track that references Essence. Defined By: SMPTE ST 377-1
|
| Filler | An MXF structure used to describe empty space on a Timeline Track. Defined By: SMPTE ST 377-1
|
| Frame Wrapping | A method for dividing and interleaving Essence Elements for each frame of Picture Essence. Defined By: SMPTE ST 379-2
|
| Generic Container | MXF data structure used to store Essence data in an MXF file. Defined By: SMPTE ST 379-2
|
| Header Metadata | MXF data structures that collectively describe the data in the Essence data in an MXF file. Defined By: SMPTE ST 377-1
|
| Header Partition | The first Partition in the MXF file. This Partition always contains a copy of the Header Metadata. Defined By: SMPTE ST 377-1
|
| Index Table | A structure in an MXF file used to efficiently access Essence data. Defined By: SMPTE ST 377-1
|
| KLV Fill | Refers to the well-defined means of inserting empty, "fill", data in an MXF file. Defined By: SMPTE ST 377-1
|
| Material Package | An MXF data structure that describes an output timeline of the file. Defined By: SMPTE ST 377-1
|
| Package | An MXF structure that aggregates one or more Tracks. Defined By: SMPTE ST 377-1
|
| Partition | A portion of the MXF file. An MXF file consists of a sequence of Partitions. Defined By: SMPTE ST 377-1
|
| Picture Essence | A type of Essence containing predominantly picture data. Defined By: SMPTE ST 377-1
|
| Picture Essence Descriptor | MXF technical metadata that describes the Picture Essence. Defined By: SMPTE ST 377-1
|
| Picture Track | A type of Essence Track that references Picture Essence. Defined By: SMPTE ST 377-1
|
| Preface | The root of the Strong Reference tree of the Header Metadata. Defined By: SMPTE ST 377-1
|
| Sequence | A Structural Metadata Class that is a Subclass of Structural Component. Defined By: SMPTE ST 377-1
|
| Sound Essence | A type of Essence containing sound data. Defined By: SMPTE ST 377-1
|
| Source Essence | Essence data referenced by a Source Package. Defined By: SMPTE ST 377-1
|
| Source Package | MXF data structure that describes source Essence. Defined By: SMPTE ST 377-1
|
| Static Track (DM) | A Track carrying unchanging Descriptive Metadata. Defined By: SMPTE ST 377-1
|
| Timecode | An annotation of elapsed time along a Track. Defined By: SMPTE ST 377-1
|
| Timecode Component | An MXF structure that stores Timecode information. Defined By: SMPTE ST 377-1
|
| Timecode Track | An MXF Track that stores one or more Timecode Components. Defined By: SMPTE ST 377-1
|
| Timeline Track | A specialized MXF Track that describes a timeline by specifying an origin and rate. Defined By: SMPTE ST 377-1
|
| Top-Level File Package | A Source Package that is internal to the file and which is directly referenced by a Material Package of the file. Defined By: SMPTE ST 377-1
|
| Track | MXF data structure used to describe the content structure. Defined By: SMPTE ST 377-1
|
Table of References
| Name | Information | ||||
|---|---|---|---|---|---|
| SMPTE RP 2057 | Text-Based Metadata Carriage in MXF
| ||||
| SMPTE ST 331 | Element and Metadata Definitions for the SDTI-CP | ||||
| SMPTE ST 377-1 | Material Exchange Format (MXF) — File Format Specification
| ||||
| SMPTE ST 377-4 | MXF Multichannel Audio Labeling Framework | ||||
| SMPTE ST 378 | MXF Operational pattern 1A (Single Item, Single Package)
| ||||
| SMPTE ST 379-2 | MXF Generic Container | ||||
| SMPTE ST 382 | Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container
| ||||
| SMPTE ST 386 | Mapping Type D-10 Essence Data to the MXF Generic Container
|