[Specification (Published & Stable)] AMWA AS-11 UK DPP HD
MXF Program Contribution - UK DPP HD

About this web page

This web page is the principal rendering / view of the AMWA AS-11 UK DPP HD 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 UK DPP HD Specification

Aims

This Specification aims to define a file format for the delivery of finished HD TV Programmes to UK Digital Production Partnership (DPP) broadcasters. 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.

Loading Specification Block Tree …

File Format

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/FF_3/
Core MXF constraints
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/MXF_Core/
- MXF File Format
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/000/
  - The file conforms to SMPTE ST 377-1:2011.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/001/
    - Section 5.2.1 of SMPTE ST 377-1:2011 sets out a non-exhaustive list of changes from SMPTE ST 377:2004.
- Operational pattern 1a
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/010/
  - The file conforms to SMPTE ST 378:2004.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/011/
    - 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
    - ID: http://www.amwa.tv/projects/rules/01/block/020/
  - The Header Partition is "Closed" and "Complete".
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/014/
    - 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.
- RIP present
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/040/
  - The file has a Random Index Pack.
- KAG size of 1
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/050/
  - Every Partition in the file uses a KLV Alignment Grid of 1.
- Generic Container
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/090/
  - The file uses the Generic Container.
- Internal Essence
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/100/
  - The Generic Container is internal to the file.
- Strict Frame Wrapping
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/110/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/E8/
    - 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
    - ID: http://www.amwa.tv/projects/rules/01/block/120/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/E19/
    - 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
  - ID: http://www.amwa.tv/projects/rules/01/block/030/
- When first created, the file includes a KLV Fill item of at least 8192 bytes in total length following the Header Metadata.
- Implementation Notes
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/note/002/
  - 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.
MXF Indexing and Partitioning strategy for CBE Essence
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/MXF_Intra/
- Index precedes Essence
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/060/
  - The file contains a complete Index Table before the Essence.
- Index all Essence
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/070/
  - The Index Table indexes every Edit Unit of every Essence Element in the file.
- Single Essence Partition
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/101/
  - The Generic Container is entirely contained in exactly one Partition.
- Indexing and Partitions
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/note/007/
  - 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.
1080i25 Class 100 AVC mapped with RP 2008
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/P001/
- The file includes RP 2027 Class 100 Picture Essence at 1080i25 with 10 bit samples and it is mapped to the file as specified in SMPTE RP 2008:2008.
  - RP 2027 Class 100 Picture Essence at 1080i25 with 10 bit samples
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/block/PE1/
    - The Picture Essence conforms to SMPTE RP 2027:2012 where: "Class" is "100"; "Television system" is "1080 line system"; "Frame Frequency" is "50i"; "The sequence parameter set and the picture parameter set shall be placed after the access unit delimiter at the beginning of every coded frame".
    - Each sample in each plane (chroma and luma) in the decoded Picture Essence has 10 bits.
    - Implementation Notes
      - Component metadata
        
        ID: http://www.amwa.tv/projects/rules/01/note/003/
      - Decoders must be able to play files that omit private SEI messages from the H.264 bitstream.
        
        Decoders must apply the parameters in the sequence parameter set and picture parameter set.
        
        With these encoding parameters the coded frame size will be 568832 bytes, including the coded frame, sequence parameter set, picture parameter set, SEI messages and/or padding for SEI messages.
        
        The decoded video always has 1080 lines, regardless of any MXF Descriptor property values.
        
        The term "Frame Frequency" is used as a heading in Table 5.2 in SMPTE RP 2027:2012, but for "50i" it is the "Field Frequency". This term is used later on in Section 5.3.
- The Material Package contains exactly one Picture Track.
- Stored Height
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/note/017/
  - Values of 540 and 544 have been observed in real files for 'Stored Height' in the 'MPEG Video Descriptor'.
    
    If the value for 'Display Height' in the 'MPEG Video Descriptor' is not set, the default value is that of 'Sampled Height', which in turn defaults to the value of 'Stored Height'. 'Display Height' needs to either be set to, or default to 540.
24-bit, 48 kHz, uncompressed PCM, mapped with ST 382
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/S001/
- One audio channel per Track
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/220/
  - Each Sound Track represents exactly one Audio Channel.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/005/
    - For example, this means that in the case of stereo audio, the audio data must be split between two MXF Sound Tracks (one Sound Track for each of the two Audio Channels).
- Uncompressed 24-bit PCM audio at 48 kHz
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/230/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/029/
    - As per Section 6 of SMPTE ST 382:2007 samples are stored as little-endian integers.
- ST 382 mapping
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/240/
  - The Sound Essence is mapped to the file using any applicable method from SMPTE ST 382:2007.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/006/
    - SMPTE ST 382:2007 describes mapping for AES3 and BWF. In the case of uncompressed PCM, as used here, the mapping for the audio sample data is the same for the AES3 and BWF mappings.
Simple sound track numbering
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/SM1/
- Each Sound Track in the Material Package has a value for "Track Number" that is unique within the set of Sound Tracks in the Material Package. This value meets the following constraints: minimum equal to 1; maximum equal to the count of Sound Tracks in the Material Package.
- The "Track Number" of each Sound Track in the Material Package is the "Audio Track Number" defined in EBU R 48 and EBU R 123.
- Implementation Notes
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/note/010/
  - This really does matter because of the separation of the physical from the logical in MXF files. Without this, decoders can only identify tracks by their track ID or the physical order in the file, which is not otherwise constrained in MXF.
    
    This applies to Material Package Sound Tracks, not those in the Source Package.
    
    This differs from the suggestion in Annex B of SMPTE ST 377-1:2011 that the Track Number be set to zero for all Material Package Tracks.

AS-11 Core DM (Descriptive Metadata)

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/550/

The file contains exactly one instance of DM_AS_11_Core DM Scheme.

DM_AS_11_Core DM Scheme

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/500S/

This DM Scheme is identified by DM_AS_11_Core (the DM Scheme Label) and has the following members: DM_AS_11_Core_Framework (the DM Framework).

DM_AS_11_Core
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/500L/
- SMPTE Metadata Registers – Labels
  Kind UL Symbol Definition
  LEAF urn:smpte:ul:060e2b34.04010101.0d010701.0b010000 DM_AS_11_Core AS-11 core metadata scheme
  View the SMPTE Metadata Registers XML file(s):
  - specification_data_files/www.amwa.tv_c0f7b64/block/500L/artefacts/Labels.xml

Kind	UL	Symbol	Definition
LEAF	urn:smpte:ul:060e2b34.04010101.0d010701.0b010000	DM_AS_11_Core	AS-11 core metadata scheme

DM_AS_11_Core_Framework

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/500F/

Framework / Group

UL: urn:smpte:ul:060e2b34.027f0101.0d010701.0b010100

Symbol: DM_AS_11_Core_Framework

Properties / Elements in the Framework:

UL	Symbol	Definition	Type Symbol	Is Optional	Restrictions
urn:smpte:ul:060e2b34.01010101.0d010701.0b010101	AS_11_Series_Title	The final name of a "group" of episodes to which the programme belongs. These episodes have a shared identification and branding and are linked by common characters, subject matter, style or story.	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d010701.0b010102	AS_11_Programme_Title	The final name of the programme used to identify it as a version of an episode. This name indicates the specific purpose for which the version was created.	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d010701.0b010103	AS_11_Episode_Title_Number	The final name of the programme used to identify it as an editorially distinct member of a series i.e. an episode. This name may include a number (or consist only of a number) indicating the position of the episode within the series.	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d010701.0b010104	AS_11_Shim_Name	The name of the AS-11 shim specification to which the MXF file conforms.	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d010701.0b01010a	AS_11_Shim_Version	The version of the AS-11 shim specification to which the MXF file conforms.	VersionType	false
urn:smpte:ul:060e2b34.01010101.0d010701.0b010105	AS_11_Audio_Track_Layout	A code to identify the scheme that describes the usage of the audio channels encoded in the file.	AS_11_Audio_Track_Layout_Enum	false
urn:smpte:ul:060e2b34.01010101.0d010701.0b010106	AS_11_Primary_Audio_Language	A code to identify the main language used on primary audio channels.	ISO_639_2_Language_Code	false
urn:smpte:ul:060e2b34.01010101.0d010701.0b010107	AS_11_Closed_Captions_Present	A flag to indicate whether the programme contains embedded (out of vision) subtitling information.	Boolean	false
urn:smpte:ul:060e2b34.01010101.0d010701.0b010108	AS_11_Closed_Captions_Type	A code to identify the editorial description of the closed captions.	AS_11_Captions_Type_Enum	true
urn:smpte:ul:060e2b34.01010101.0d010701.0b010109	AS_11_Caption_Language	A code to identify the main language used in the closed captions.	ISO_639_2_Language_Code	true

Summary view of Types defined for use by this Framework

AS_11_Captions_Type_Enum

Symbol	Name	Value
Captions_Hard_of_Hearing	Hard of Hearing	0
Captions_Translation	Translation	1

AS_11_Audio_Track_Layout_Enum

Symbol	Name	Value
Layout_EBU_R_48_1a	EBU R 48: 1a	0
Layout_EBU_R_48_1b	EBU R 48: 1b	1
Layout_EBU_R_48_1c	EBU R 48: 1c	2
Layout_EBU_R_48_2a	EBU R 48: 2a	3
Layout_EBU_R_48_2b	EBU R 48: 2b	4
Layout_EBU_R_48_2c	EBU R 48: 2c	5
Layout_EBU_R_48_3a	EBU R 48: 3a	6
Layout_EBU_R_48_3b	EBU R 48: 3b	7
Layout_EBU_R_48_4a	EBU R 48: 4a	8
Layout_EBU_R_48_4b	EBU R 48: 4b	9
Layout_EBU_R_48_4c	EBU R 48: 4c	10
Layout_EBU_R_48_5a	EBU R 48: 5a	11
Layout_EBU_R_48_5b	EBU R 48: 5b	12
Layout_EBU_R_48_6a	EBU R 48: 6a	13
Layout_EBU_R_48_6b	EBU R 48: 6b	14
Layout_EBU_R_48_7a	EBU R 48: 7a	15
Layout_EBU_R_48_7b	EBU R 48: 7b	16
Layout_EBU_R_48_8a	EBU R 48: 8a	17
Layout_EBU_R_48_8b	EBU R 48: 8b	18
Layout_EBU_R_48_8c	EBU R 48: 8c	19
Layout_EBU_R_48_9a	EBU R 48: 9a	20
Layout_EBU_R_48_9b	EBU R 48: 9b	21
Layout_EBU_R_48_10a	EBU R 48: 10a	22
Layout_EBU_R_48_11a	EBU R 48: 11a	23
Layout_EBU_R_48_11b	EBU R 48: 11b	24
Layout_EBU_R_48_11c	EBU R 48: 11c	25
Layout_EBU_R_123_2a	EBU R 123: 2a	26
Layout_EBU_R_123_4a	EBU R 123: 4a	27
Layout_EBU_R_123_4b	EBU R 123: 4b	28
Layout_EBU_R_123_4c	EBU R 123: 4c	29
Layout_EBU_R_123_8a	EBU R 123: 8a	30
Layout_EBU_R_123_8b	EBU R 123: 8b	31
Layout_EBU_R_123_8c	EBU R 123: 8c	32
Layout_EBU_R_123_8d	EBU R 123: 8d	33
Layout_EBU_R_123_8e	EBU R 123: 8e	34
Layout_EBU_R_123_8f	EBU R 123: 8f	35
Layout_EBU_R_123_8g	EBU R 123: 8g	36
Layout_EBU_R_123_8h	EBU R 123: 8h	37
Layout_EBU_R_123_8i	EBU R 123: 8i	38
Layout_EBU_R_123_12a	EBU R 123: 12a	39
Layout_EBU_R_123_12b	EBU R 123: 12b	40
Layout_EBU_R_123_12c	EBU R 123: 12c	41
Layout_EBU_R_123_12d	EBU R 123: 12d	42
Layout_EBU_R_123_12e	EBU R 123: 12e	43
Layout_EBU_R_123_12f	EBU R 123: 12f	44
Layout_EBU_R_123_12g	EBU R 123: 12g	45
Layout_EBU_R_123_12h	EBU R 123: 12h	46
Layout_EBU_R_123_16a	EBU R 123: 16a	47
Layout_EBU_R_123_16b	EBU R 123: 16b	48
Layout_EBU_R_123_16c	EBU R 123: 16c	49
Layout_EBU_R_123_16d	EBU R 123: 16d	50
Layout_EBU_R_123_16e	EBU R 123: 16e	51
Layout_EBU_R_123_16f	EBU R 123: 16f	52
Layout_Undefined	Undefined	255

ISO_639_2_Language_Code

A three-letter (alpha-3) ISO 639-2 code to represent a language

Renames UTF16String

Note: Be aware that ISO 639-2 defines: both bibliographic and terminologic language codes; that language codes are case insensitive

View the SMPTE Metadata Registers XML file(s):

Metadata Constraints as Python

For an explanation of the format of this Python Artefact refer to the associated Specification Format Definition.

"""
This file details additional core constraints on DM_AS_11_Core_Framework that
are not expressed in the entries in the SMPTE Metadata Registers.
"""

# Note that there is no "else" statement on any of these. Hence there is no
# restriction on the non-presence of conditional fields when they are not required.
if (AS_11_Closed_Captions_Present):
    CHECK( PRESENT(AS_11_Closed_Captions_Type) )
    CHECK( PRESENT(AS_11_Caption_Language) )

View the Python file:

specification_data_files/www.amwa.tv_c0f7b64/block/500F/artefacts/dm_extras.py

The DM Framework instance is strongly referenced from a Constrained Static DM Track.
- Constrained Static DM Track
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/056/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/039/
    - 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".
Repetition of Header Metadata
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/note/051/
- Repetition of Header Metadata in the Footer Partition is not considered to be another instance of any of the components of that Header Metadata.

AS-11 UKDPP DM (Descriptive Metadata)

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/555/

The file contains exactly one instance of DM_AS_11_UKDPP DM Scheme.

DM_AS_11_UKDPP DM Scheme

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/510S/

This DM Scheme is identified by DM_AS_11_UKDPP (the DM Scheme Label) and has the following members: DM_AS_11_UKDPP Framework (the DM Framework).

DM_AS_11_UKDPP
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/510L/
- SMPTE Metadata Registers – Labels
  Kind UL Symbol Definition
  LEAF urn:smpte:ul:060e2b34.04010101.0d0c0101.01000000 DM_AS_11_UKDPP AS-11 UK DPP metadata scheme
  View the SMPTE Metadata Registers XML file(s):
  - specification_data_files/www.amwa.tv_c0f7b64/block/510L/artefacts/Labels.xml

Kind	UL	Symbol	Definition
LEAF	urn:smpte:ul:060e2b34.04010101.0d0c0101.01000000	DM_AS_11_UKDPP	AS-11 UK DPP metadata scheme

DM_AS_11_UKDPP Framework

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/510F/

Framework / Group

UL: urn:smpte:ul:060e2b34.027f0101.0d0c0101.01010000

Symbol: DM_AS_11_UKDPP_Framework

Properties / Elements in the Framework:

UL	Symbol	Definition	Type Symbol	Is Optional	Restrictions
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010100	UKDPP_Production_Number	A unique identifier / code for the programme (i.e. a unique identifier for this version of the episode).	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010200	UKDPP_Synopsis	A brief descriptive summary of the programme.	UTF16String	false	250 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010300	UKDPP_Originator	The name of the person or organisation responsible for creating the programme.	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010400	UKDPP_Copyright_Year	The full year in which one of the following occurred or will occur: completion of the production of the programme; delivery of the completed file to the Broadcaster; transmission of the delivered programme.	UInt16	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010500	UKDPP_Other_Identifier	Another unique identifier / code for the content.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010600	UKDPP_Other_Identifier_Type	The kind of identifier / code used for "Other Identifier".	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010700	UKDPP_Genre	A single style or category describing the whole programme.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010800	UKDPP_Distributor	The name of the person or organisation responsible for supplying the programme to the Broadcaster.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010900	UKDPP_Picture_Ratio	The ratio of the display width to the display height of the smallest rectangle that completely contains (throughout the duration of the entire programme) the region of the video frame used for "programme content" (where "programme content" includes all pictures, captions, etc but excludes any black bars).	Rational	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010a00	UKDPP_3D	A flag to indicate whether the file contains video intended for stereoscopic rendition.	Boolean	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010b00	UKDPP_3D_Type	A code to identify the kind of stereoscopic video contained in the file.	UKDPP_3D_Type_Enum	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010c00	UKDPP_Product_Placement	A flag to indicate whether the programme contains "product placement".	Boolean	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010d00	UKDPP_PSE_Pass	A code to indicate: whether the entire programme passed a flash and pattern test for compliance with Photosensitive Epilepsy (PSE) guidelines; or that such a test has not been carried out.	UKDPP_PSE_Pass_Enum	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010e00	UKDPP_PSE_Manufacturer	The name of the product used to perform the test for compliance with PSE guidelines.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01010f00	UKDPP_PSE_Version	The version of the algorithm / product module used to perform the test for compliance with PSE guidelines.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011000	UKDPP_Video_Comments	A description of the subjective quality of the video in the programme including notes on any global characteristics or video treatments.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011100	UKDPP_Secondary_Audio_Language	A code to identify the main language used on secondary audio channels.	ISO_639_2_Language_Code	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011200	UKDPP_Tertiary_Audio_Language	A code to identify the main language used on tertiary audio channels.	ISO_639_2_Language_Code	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011300	UKDPP_Audio_Loudness_Standard	A code to identify a relevant audio loudness recommendation or standard.	UKDPP_Audio_Loudness_Standard_Enum	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011400	UKDPP_Audio_Comments	A description of the subjective quality of the audio in the programme including notes on any global characteristics or audio treatments.	UTF16String	true	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011500	UKDPP_Line_Up_Start	The value of the Position in the MXF Material Package at which the line-up test signals begin.	PositionType	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011600	UKDPP_Ident_Clock_Start	The value of the Position in the MXF Material Package at which the initial "ident" or countdown clock begins.	PositionType	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011700	UKDPP_Total_Number_Of_Parts	The count of parts / segments in the file.	UInt16	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011800	UKDPP_Total_Programme_Duration	The sum of the durations of all the parts / segments in the entire programme.	LengthType	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011900	UKDPP_Audio_Description_Present	A flag to indicate whether the programme contains audio description for the visually impaired.	Boolean	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011a00	UKDPP_Audio_Description_Type	A code to identify the format of the audio description.	UKDPP_Audio_Description_Type_Enum	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011b00	UKDPP_Open_Captions_Present	A flag to indicate whether the programme contains visible (in-vision) subtitling information.	Boolean	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011c00	UKDPP_Open_Captions_Type	A code to identify the editorial description of the open captions.	AS_11_Captions_Type_Enum	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011d00	UKDPP_Open_Captions_Language	A code to identify the main language used in the open captions.	ISO_639_2_Language_Code	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011e00	UKDPP_Signing_Present	A code to indicate: whether the programme contains visible (in-vision) signing along with the rest of the programme content; or that the programme contains only visible (in-vision) signing.	UKDPP_Signing_Present_Enum	false
urn:smpte:ul:060e2b34.01010101.0d0c0101.01011f00	UKDPP_Sign_Language	A code to identify the main language and / or format of the visible (in-vision) signing contained in the programme.	UKDPP_Sign_Language_Enum	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01012000	UKDPP_Completion_Date	The date on which the programme file was completed ready for delivery to the Broadcaster.	TimeStamp	false	All facets of the "Time" facet of this "TimeStamp" are zero
urn:smpte:ul:060e2b34.01010101.0d0c0101.01012100	UKDPP_Textless_Elements_Exist	A flag to indicate whether the programme contains "textless elements" after the end of the main programme content.	Boolean	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01012200	UKDPP_Programme_Has_Text	A flag to indicate whether the main programme content contains text overlays (or similar) in the video.	Boolean	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01012300	UKDPP_Programme_Text_Language	A code to identify the main language used for text overlays (or similar) in the video of the main programme content.	ISO_639_2_Language_Code	true
urn:smpte:ul:060e2b34.01010101.0d0c0101.01012400	UKDPP_Contact_Email	The email address for the person or organisation responsible for supplying the programme file to the Broadcaster.	UTF16String	false	127 Unicode "code points" maximum
urn:smpte:ul:060e2b34.01010101.0d0c0101.01012500	UKDPP_Contact_Telephone_Number	The telephone number for the person or organisation responsible for supplying the programme file to the Broadcaster.	UTF16String	false	127 Unicode "code points" maximum

Summary view of Types defined for use by this Framework

AS_11_Captions_Type_Enum

Symbol	Name	Value
Captions_Hard_of_Hearing	Hard of Hearing	0
Captions_Translation	Translation	1

ISO_639_2_Language_Code

A three-letter (alpha-3) ISO 639-2 code to represent a language

Renames UTF16String

Note: Be aware that ISO 639-2 defines: both bibliographic and terminologic language codes; that language codes are case insensitive

UKDPP_PSE_Pass_Enum

Symbol	Name	Value
PSE_Yes	Yes	0
PSE_No	No	1
PSE_Not_tested	Not tested	2

UKDPP_Signing_Present_Enum

Symbol	Name	Value
Signing_Yes	Yes	0
Signing_No	No	1
Signing_Signer_only	Signer only	2

UKDPP_3D_Type_Enum

Symbol	Name	Value
ThreeD_Side_by_side	Side by side	0
ThreeD_Dual	Dual	1
ThreeD_Left_eye_only	Left eye only	2
ThreeD_Right_eye_only	Right eye only	3

UKDPP_Audio_Loudness_Standard_Enum

Symbol	Name	Value
Loudness_None	None	0
Loudness_EBU_R_128	EBU R 128	1

UKDPP_Audio_Description_Type_Enum

Symbol	Name	Value
AD_Control_data_Narration	Control data / Narration	0
AD_Mix	AD Mix	1

UKDPP_Sign_Language_Enum

Symbol	Name	Value
Sign_Language_BSL_British_Sign_Language	BSL (British Sign Language)	0
Sign_Language_BSL_Makaton	BSL (Makaton)	1

View the SMPTE Metadata Registers XML file(s):

Metadata Constraints as Python

For an explanation of the format of this Python Artefact refer to the associated Specification Format Definition.

"""
This file details additional core constraints on DM_AS_11_UKDPP_Framework that
are not expressed in the entries in the SMPTE Metadata Registers.
"""

# Note that there is no "else" statement on any of these. Hence there is no
# restriction on the non-presence of conditional fields when they are not required.
if PRESENT(UKDPP_Other_Identifier):
    CHECK( PRESENT(UKDPP_Other_Identifier_Type) )

if UKDPP_3D:
    CHECK( PRESENT(UKDPP_3D_Type) )

if UKDPP_PSE_Pass != PSE_Not_tested:
    CHECK( PRESENT(UKDPP_PSE_Manufacturer) )
    CHECK( PRESENT(UKDPP_PSE_Version) )

if UKDPP_Audio_Description_Present:
    CHECK( PRESENT(UKDPP_Audio_Description_Type) )

if UKDPP_Open_Captions_Present:
    CHECK( PRESENT(UKDPP_Open_Captions_Type) )
    CHECK( PRESENT(UKDPP_Open_Captions_Language) )

if UKDPP_Signing_Present in [Signing_Yes, Signing_Signer_only]:
    CHECK( PRESENT(UKDPP_Sign_Language) )

if PRESENT(UKDPP_Programme_Has_Text) and UKDPP_Programme_Has_Text:
    CHECK( PRESENT(UKDPP_Programme_Text_Language) )

View the Python file:

specification_data_files/www.amwa.tv_c0f7b64/block/510F/artefacts/dm_extras.py

The DM Framework instance is strongly referenced from a Constrained Static DM Track.
- Constrained Static DM Track
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/056/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/039/
    - 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".
Repetition of Header Metadata
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/note/051/
- Repetition of Header Metadata in the Footer Partition is not considered to be another instance of any of the components of that Header Metadata.

AS-11 Segmentation DM (Descriptive Metadata)

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/530/
The file contains exactly one Program Segmentation Track.
- Program Segmentation Track
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/532/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/038/
    - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/040/
    - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/048/
    - 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
- ID: http://www.amwa.tv/projects/rules/01/block/505S/

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
  - ID: http://www.amwa.tv/projects/rules/01/block/505L/
- 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):
  - specification_data_files/www.amwa.tv_c0f7b64/block/505L/artefacts/Labels.xml

Kind	UL	Symbol	Definition
LEAF	urn:smpte:ul:060e2b34.04010101.0d010701.0b020000	DM_AS_11_Segmentation	AS-11 segmentation metadata scheme

DM_AS_11_Segmentation_Framework

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/505F/

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):

Implementation Notes
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/note/049_r001/
- 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
  - ID: http://www.amwa.tv/projects/rules/01/note/051/
- Repetition of Header Metadata in the Footer Partition is not considered to be another instance of any of the components of that Header Metadata.

Dolby Audio Metadata (Optional)
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/DAM/
- The Dolby E Audio Metadata Serial Bitstream that describes an Audio Program is included in the file using Dolby E Audio Metadata Serial Bitstream Carriage.
  - Dolby E Audio Metadata Serial Bitstream Carriage
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/block/400/
    - The mapping of a Dolby E Audio Metadata Serial Bitstream into VANC Data Packets conforms to SMPTE 2020-B.
    - The mapping of VANC Data Packets into ANC Frame Elements is as specified in Constrained Ancillary Data Mapping.
      - Constrained Ancillary Data Mapping
        
        Component metadata
        
        ID: http://www.amwa.tv/projects/rules/01/block/402/
        
        The mapping of VANC Data Packets into ANC Frame Elements is as specified in SMPTE ST 436-1:2013 where "Payload Sample Coding" is "8-bit luma samples" (04h) and "Wrapping Type" is: "VANC Frame" (01h) (for interlaced or segmented progressive Picture Essence) or "VANC Progressive Frame" (04h) (for full-frame progressive Picture Essence).
    - The "Line Number" used for each field's VANC Data Packet in the ANC Frame Element is the same for all VANC Data Packets for that field for the identified Audio Program.
    - Implementation Notes
      - Component metadata
        
        ID: http://www.amwa.tv/projects/rules/01/note/E2/
      - Use of Dolby E Audio Metadata Serial Bitstream Carriage
        
        The file can use Dolby E Audio Metadata Serial Bitstream Carriage to carry audio presentation metadata for zero, one or more than one SoundfieldGroups / Audio Programs.
        
        SDID value
        
        SMPTE ST 2020-1 specifies that the SDID value within the VANC Data Packet be used to identify the Sound Tracks that make up the Audio Program. For example, VANC Data Packets that contain Dolby E Audio Metadata Serial Bitstream for a 5.1 channel Audio Program starting at channel pair 5/6 will require the SDID value in the VANC Data Packet to be set to 04h.
        
        However, this approach only works inside an MXF file if every Audio Channel in the file is identifiable using a pan-file channel number. This is the case if, for example, the Sound Tracks in the MXF file are numbered mono Sound Tracks.
        
        However, if the Sound Tracks in the MXF file are Multichannel Sound Tracks then this approach does not work. Some consequences of this:
        
        The value to be used for SDID is undefined.
        
        If more than one 5.1 SoundfieldGroup (and at least one Dolby E Audio Metadata Serial Bitstream) is included in the file then an external mechanism is needed to relate SoundfieldGroups and Dolby E Audio Metadata Serial Bitstreams.
        
        The SDID values might need to be rewritten upon output so that they correctly identify the Audio Channels that are being used to carry the relevant SoundfieldGroup / Audio Program. For example, this might be the case when playing out an MXF file to SDI -- particularly if only certain audio is played out or the audio layout is changed.
        
        DID value
        
        VANC Data Packets that are carrying Dolby E Audio Metadata Serial Bitstream will have a DID value of 45h.
        
        Packets are not constant throughout
        
        SMPTE 2020-B requires that there is "one packet in each field of interlaced video formats". However, the two packets in each interlaced video frame are not identical.
        
        The values of SMPTE RDD 6 metadata properties might change from one frame to the next, but normally they will not. However, the VANC Data Packets in the file will not be identical even if the metadata is static: the "frame_count" will certainly increment and the "description_text" (if not null) will change.
        
        Other data being carried in the ANC Frame Element
        
        The ANC Frame Element can also contain HANC Data Packets and other VANC Data Packets in addition to those carrying Dolby E Audio Metadata Serial Bitstreams. Irrespective of what data is carried in the ANC Frame Element, there is only ever one Track (in each of the Material Package and Top-Level File Package), one Data Element, and one associated Essence Descriptor in the MXF file.
Timecode constraints
- Component metadata
  - ID: http://www.amwa.tv/projects/rules/01/block/TT0_r001/
- Timecode Track Presence
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/280/
  - The Material Package contains exactly one Timecode Track.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/021/
    - 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
    - ID: http://www.amwa.tv/projects/rules/01/block/TTC_MP/
  - The Timecode Track in the Material Package is a Constrained Timecode Track.
    - Constrained Timecode Track
      - Component metadata
        
        ID: http://www.amwa.tv/projects/rules/01/block/TTC/
      - A Constrained Timecode Track is a Timecode Track.
      - 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
    - ID: http://www.amwa.tv/projects/rules/01/block/DF/
  - 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 60 and the "Edit Rate" of the Timecode Track is mathematically equal to 60000/1001
    - The "Rounded Timecode Base" property of the Timecode Component is 30 and the "Edit Rate" of the Timecode Track is mathematically equal to 30000/1001
  - Rational Numbers
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/E69/
    - 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/5 is mathematically equal to 14/10.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/E81/
    - 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
    - ID: http://www.amwa.tv/projects/rules/01/block/290/
  - The Timecode Track in the Material Package defines the authoritative program timecode.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/022/
    - 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
  - ID: http://www.amwa.tv/projects/rules/01/block/999/
- AFD present
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/350/
  - The "Active Format Descriptor" property of the Picture Essence Descriptor is present in the file.
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/036/
    - 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
    - ID: http://www.amwa.tv/projects/rules/01/block/351/
  - 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
      - ID: http://www.amwa.tv/projects/rules/01/note/037/
    - 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 or 16 audio channels
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/210/
  - There are either exactly 4 or exactly 16 Audio Channels in the file.
- R48 2a customisation
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/270/
  - The number of Audio Channels described by the scheme identified by the value of AS_11_Audio_Track_Layout is equal to the number of Audio Channels in the file except that a value of Layout_EBU_R_48_2a is permitted when all of the following are true:
    - there are four Audio Channels in the file
    - for each Sound Track in the Material Package with a "Track Number" of 3 or 4 the Sound Essence contains digital silence
  - Implementation Notes
    - Component metadata
      - ID: http://www.amwa.tv/projects/rules/01/note/019/
    - MXF Filler cannot be used here to represent silence.
- No Closed Captions
  - Component metadata
    - ID: http://www.amwa.tv/projects/rules/01/block/300/
  - The file does not contain closed captions.

Miscellaneous DM constraints (Descriptive Metadata)

Component metadata
- ID: http://www.amwa.tv/projects/rules/01/block/989/

Metadata Constraints as Python

For an explanation of the format of this Python Artefact refer to the associated Specification Format Definition.

CHECK( AS_11_Audio_Track_Layout in [Layout_EBU_R_48_2a,
                                    Layout_EBU_R_123_4b,
                                    Layout_EBU_R_123_4c,
                                    Layout_EBU_R_123_16c,
                                    Layout_EBU_R_123_16d,
                                    Layout_EBU_R_123_16f] )

View the Python file:

specification_data_files/www.amwa.tv_c0f7b64/block/989/artefacts/audio_track_layout.py

Metadata Constraints as Python
For an explanation of the format of this Python Artefact refer to the associated Specification Format Definition.
```
CHECK( AS_11_Shim_Name == "UK DPP HD" )
CHECK( AS_11_Shim_Version == {"VersionMajor":1, "VersionMinor":1} )
```
View the Python file:
- specification_data_files/www.amwa.tv_c0f7b64/block/989/artefacts/shim.py

Metadata Constraints as Python

For an explanation of the format of this Python Artefact refer to the associated Specification Format Definition.

if PRESENT( UKDPP_Picture_Ratio ):
    CHECK( UKDPP_Picture_Ratio in [{"Numerator":4, "Denominator":3},
                                   {"Numerator":14, "Denominator":9},
                                   {"Numerator":15, "Denominator":9},
                                   {"Numerator":16, "Denominator":9},
                                   {"Numerator":37, "Denominator":20},
                                   {"Numerator":21, "Denominator":9},
                                   {"Numerator":12, "Denominator":5}] )

View the Python file:

specification_data_files/www.amwa.tv_c0f7b64/block/989/artefacts/picture_ratio.py

Table of Terms

Term	Explanation
ANC Frame Element	A KLV triplet containing one frame's worth of an Essence Element carrying ANC packets such as VANC Data Packets. ID: http://www.amwa.tv/projects/rules/01/term/ANC%20Frame%20Element/ Defined By: SMPTE ST 436-1
Audio Channel	A distinct collection of sequenced audio samples that are intended for delivery to a single loudspeaker or other reproduction device. ID: http://www.amwa.tv/projects/rules/01/term/Audio%20Channel/ Defined By: SMPTE ST 377-4
Audio Program	A collection of one or more audio channels. ID: http://www.amwa.tv/projects/rules/01/term/Audio%20Program/ Defined By: SMPTE ST 2020-1
Descriptive Metadata	Generic term used for descriptive data whose purpose is to describe Essence data. ID: http://www.amwa.tv/projects/rules/01/term/Descriptive%20Metadata/ Defined By: SMPTE ST 377-1
DM Framework	A Descriptive Metadata Class that is a Subclass of Descriptive Framework. ID: http://www.amwa.tv/projects/rules/01/term/DM%20Framework/ Defined By: SMPTE ST 377-1
DM Scheme	A mechanism for defining collections of Descriptive Metadata. ID: http://www.amwa.tv/projects/rules/01/term/DM%20Scheme/ 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. ID: http://www.amwa.tv/projects/rules/01/term/DM%20Scheme%20Label/ Defined By: SMPTE ST 377-1
DM Segment	An MXF structure used to generically contain Descriptive Metadata on a Track. ID: http://www.amwa.tv/projects/rules/01/term/DM%20Segment/ Defined By: SMPTE ST 377-1
Dolby E Audio Metadata Serial Bitstream	A serial communication protocol that is used to transfer audio metadata between various products manufactured by Dolby. ID: http://www.amwa.tv/projects/rules/01/term/Dolby%20E%20Audio%20Metadata%20Serial%20Bitstream/ Defined By: SMPTE RDD 6
Edit Unit	A temporal division of a Track. ID: http://www.amwa.tv/projects/rules/01/term/Edit%20Unit/ Defined By: SMPTE ST 377-1
Essence	A bitstream comprising picture, sound or data. ID: http://www.amwa.tv/projects/rules/01/term/Essence/ Defined By: SMPTE ST 377-1
Essence Element	The entire essence stream of a single Track. ID: http://www.amwa.tv/projects/rules/01/term/Essence%20Element/ Defined By: SMPTE ST 379-2
Essence Track	A type of Track that references Essence. ID: http://www.amwa.tv/projects/rules/01/term/Essence%20Track/ Defined By: SMPTE ST 377-1
Filler	An MXF structure used to describe empty space on a Timeline Track. ID: http://www.amwa.tv/projects/rules/01/term/Filler/ Defined By: SMPTE ST 377-1
Frame Wrapping	A method for dividing and interleaving Essence Elements for each frame of Picture Essence. ID: http://www.amwa.tv/projects/rules/01/term/Frame%20Wrapping/ Defined By: SMPTE ST 379-2
Generic Container	MXF data structure used to store Essence data in an MXF file. ID: http://www.amwa.tv/projects/rules/01/term/Generic%20Container/ Defined By: SMPTE ST 379-2
Header Metadata	MXF data structures that collectively describe the data in the Essence data in an MXF file. ID: http://www.amwa.tv/projects/rules/01/term/Header%20Metadata/ 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. ID: http://www.amwa.tv/projects/rules/01/term/Header%20Partition/ Defined By: SMPTE ST 377-1
Index Table	A structure in an MXF file used to efficiently access Essence data. ID: http://www.amwa.tv/projects/rules/01/term/Index%20Table/ Defined By: SMPTE ST 377-1
KLV Alignment Grid	A notional byte spacing which may be used to align KLV items within a Partition. ID: http://www.amwa.tv/projects/rules/01/term/KLV%20Alignment%20Grid/ Defined By: SMPTE ST 377-1
KLV Fill	Refers to the well-defined means of inserting empty, "fill", data in an MXF file. ID: http://www.amwa.tv/projects/rules/01/term/KLV%20Fill/ Defined By: SMPTE ST 377-1
Material Package	An MXF data structure that describes an output timeline of the file. ID: http://www.amwa.tv/projects/rules/01/term/Material%20Package/ Defined By: SMPTE ST 377-1
Package	An MXF structure that aggregates one or more Tracks. ID: http://www.amwa.tv/projects/rules/01/term/Package/ Defined By: SMPTE ST 377-1
Partition	A portion of the MXF file. An MXF file consists of a sequence of Partitions. ID: http://www.amwa.tv/projects/rules/01/term/Partition/ Defined By: SMPTE ST 377-1
Picture Essence	A type of Essence containing predominantly picture data. ID: http://www.amwa.tv/projects/rules/01/term/Picture%20Essence/ Defined By: SMPTE ST 377-1
Picture Essence Descriptor	MXF technical metadata that describes the Picture Essence. ID: http://www.amwa.tv/projects/rules/01/term/Picture%20Essence%20Descriptor/ Defined By: SMPTE ST 377-1
Picture Track	A type of Essence Track that references Picture Essence. ID: http://www.amwa.tv/projects/rules/01/term/Picture%20Track/ Defined By: SMPTE ST 377-1
Random Index Pack	A table that contains the byte offsets of all Partitions. ID: http://www.amwa.tv/projects/rules/01/term/Random%20Index%20Pack/ Defined By: SMPTE ST 377-1
Sequence	A Structural Metadata Class that is a Subclass of Structural Component. ID: http://www.amwa.tv/projects/rules/01/term/Sequence/ Defined By: SMPTE ST 377-1
SMPTE 2020-B	A method (sometimes known as "Method B") for mapping audio metadata into vertical ancillary data. ID: http://www.amwa.tv/projects/rules/01/term/SMPTE%202020-B/ Defined By: SMPTE ST 2020-1
Sound Essence	A type of Essence containing sound data. ID: http://www.amwa.tv/projects/rules/01/term/Sound%20Essence/ Defined By: SMPTE ST 377-1
Sound Track	A type of Essence Track that references Sound Essence. ID: http://www.amwa.tv/projects/rules/01/term/Sound%20Track/ Defined By: SMPTE ST 377-1
Source Essence	Essence data referenced by a Source Package. ID: http://www.amwa.tv/projects/rules/01/term/Source%20Essence/ Defined By: SMPTE ST 377-1
Source Package	MXF data structure that describes source Essence. ID: http://www.amwa.tv/projects/rules/01/term/Source%20Package/ Defined By: SMPTE ST 377-1
Static Track (DM)	A Track carrying unchanging Descriptive Metadata. ID: http://www.amwa.tv/projects/rules/01/term/Static%20Track%20(DM)/ Defined By: SMPTE ST 377-1
Timecode	An annotation of elapsed time along a Track. ID: http://www.amwa.tv/projects/rules/01/term/Timecode/ Defined By: SMPTE ST 377-1
Timecode Component	An MXF structure that stores Timecode information. ID: http://www.amwa.tv/projects/rules/01/term/Timecode%20Component/ Defined By: SMPTE ST 377-1
Timecode Track	An MXF Track that stores one or more Timecode Components. ID: http://www.amwa.tv/projects/rules/01/term/Timecode%20Track/ Defined By: SMPTE ST 377-1
Timeline Track	A specialized MXF Track that describes a timeline by specifying an origin and rate. ID: http://www.amwa.tv/projects/rules/01/term/Timeline%20Track/ 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. ID: http://www.amwa.tv/projects/rules/01/term/Top-Level%20File%20Package/ Defined By: SMPTE ST 377-1
Track	MXF data structure used to describe the content structure. ID: http://www.amwa.tv/projects/rules/01/term/Track/ Defined By: SMPTE ST 377-1
VANC Data Packet	An ancillary data packet in the vertical ancillary data space (VANC). ID: http://www.amwa.tv/projects/rules/01/term/VANC%20Data%20Packet/ Defined By: SMPTE ST 291-1

Table of References

Name

Information

EBU R 123

Audio Track Allocation for File Exchange

ID: http://www.amwa.tv/projects/rules/01/external_reference/EBU%20R%20123/

EBU R 123
Audio Track Allocation for File Exchange https://tech.ebu.ch/docs/r/r123.pdf ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/EBU%20R%20123-2009/

EBU R 48

Allocation of audio tracks on digital television recorders

ID: http://www.amwa.tv/projects/rules/01/external_reference/EBU%20R%2048/

EBU R 48
Allocation of audio tracks on digital television recorders https://tech.ebu.ch/publications/r048 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/EBU%20R%2048-2005/

SMPTE RDD 6

Description and Guide to the Use of the Dolby E Audio Metadata Serial Bitstream

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20RDD%206/

SMPTE RP 2008

Material Exchange Format — Mapping AVC Streams into the MXF Generic Container

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20RP%202008/

SMPTE RP 2008:2008
Material Exchange Format — Mapping AVC Streams into the MXF Generic Container http://dx.doi.org/10.5594/SMPTE.RP2008.2008 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20RP%202008-2008/

SMPTE RP 2027

AVC Intra-frame Coding Specification for SSM Card Applications

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20RP%202027/

SMPTE RP 2027:2012
AVC Intra-frame Coding Specification for SSM Card Applications http://dx.doi.org/10.5594/SMPTE.RP2027.2012 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20RP%202027-2012/

SMPTE ST 2020-1

Format of Audio Metadata and Description of the Asynchronous Serial Bitstream Transport

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%202020-1/

SMPTE ST 291-1

Ancillary Data Packet and Space Formatting

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20291-1/

SMPTE ST 377-1

Material Exchange Format (MXF) — File Format Specification

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20377-1/

SMPTE ST 377-1:2011
Material Exchange Format (MXF) — File Format Specification http://dx.doi.org/10.5594/SMPTE.ST377-1.2011 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20ST%20377-1-2011/

SMPTE ST 377:2004
Material Exchange Format (MXF) −− File Format Specification http://dx.doi.org/10.5594/SMPTE.ST377.2004 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20ST%20377-1-2004/

SMPTE ST 377-4

MXF Multichannel Audio Labeling Framework

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20377-4/

SMPTE ST 378

MXF Operational pattern 1A (Single Item, Single Package)

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20378/

SMPTE ST 378:2004
MXF Operational pattern 1A (Single Item, Single Package) http://dx.doi.org/10.5594/SMPTE.ST378.2004 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20ST%20378-2004/

SMPTE ST 379-2

MXF Generic Container

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20379-2/

SMPTE ST 382

Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20382/

SMPTE ST 382:2007
Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container http://dx.doi.org/10.5594/SMPTE.ST382.2007 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20ST%20382-2007/

SMPTE ST 436-1

MXF Mappings for VI Lines and Ancillary Data Packets

ID: http://www.amwa.tv/projects/rules/01/external_reference/SMPTE%20ST%20436-1/

SMPTE ST 436-1:2013
MXF Mappings for VI Lines and Ancillary Data Packets http://dx.doi.org/10.5594/SMPTE.ST436-1.2013 ID: http://www.amwa.tv/projects/rules/01/external_reference_revision/SMPTE%20ST%20436-1-2013/

Metadata Constraints as Python Artefacts: Specification Format Definition

This Section defines how Python Artefacts (expressing metadata constraints) in this Specification are to be interpreted.

Each Python Artefact defines checks / tests using Python version 2.7. An implementation complies with a Python Artefact if it passes all of the checks / tests that the Artefact specifies. Note that the code has been designed to enhance the clarity of the test definitions rather than for efficient or compact code.

Each relevant MXF Element / property is represented as a Python variable:

The name of the variable is set as the Symbol of the Element / property.
The value of the variable must be None (i.e. the special Python object) if the Element / property is considered to be "absent" from the relevant KLV set in the MXF file (an Element / property is considered to be "present" in the MXF file if its 2-byte tag is present in the relevant KLV set in the MXF file and it is considered to be "absent" otherwise). Otherwise the value stored in the MXF file must be converted into the relevant Python data type (see below).

Data Types

UTF16String

Values of Type UTF16String are stored as Python Unicode strings. UTF16String values are assumed to have been read from the MXF file according to Section 4.3 of SMPTE ST 377-1:2011, terminating before (and discarding) any null character. Note that no other characters appearing before the null character (such as whitespace or non-printable characters) are removed. If an Element / property of type UTF16String is considered "present" but the above processing of the value stored in the MXF file results in zero characters in the string, the corresponding variable shall be assigned the value "" (the empty string).

Integers

All signed and unsigned integer types used in MXF are represented as Python integers.

Booleans

The values of MXF Booleans are represented by the Python values True and False.

Record Types

Any value of a "Record" Type (a Type with TypeKind of Record) is represented as a Python Dictionary. For each Facet (constituent part) an item is added to the Python Dictionary with a key equal to that of the Symbol of the Facet. The value for this key is set to the parsed value of the relevant portion of the Element / property value.

Enumerations

For each Facet (allowed value) of an "Enumeration" Type (a Type with TypeKind of Enumeration) a Python variable is defined with:

a name equal to that of the Facet Symbol
a value equal to that of the Facet Value

Helper Functions

The following helper functions are used in the Python Artefacts. They have been designed to enhance clarity rather than for efficient or compact code.

def CHECK(condition):
    """
    Check that the provided 'condition' (Boolean) is True.

    If the provided 'condition' is False this is a 'Fail' -- the implementation
    does not comply with the constraint.

    """

    try:
        assert condition == True
    except AssertionError:
        print "Check failed -- compliance has not been achieved"

def PRESENT(variable):
    """
    Return a Boolean to indicate whether the Element / property represented by
    the 'variable' is present in the MXF file.

    'Presence' of an Element / property is determined by the presence of its
    2-byte tag in the relevant KLV set in the MXF file. The Python variable
    representing an MXF Element / property is assumed to be None if, and
    only if, that Element / property is considered not present in the MXF file.

    """

    if variable is not None:
        return True
    else:
        return False

THIS AMWA SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER AMWA, NOR ANY OF ITS MEMBERS OR CONTRIBUTORS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Readers are advised that any IPR contribution forms associated with this project are available from the AMWA

[Specification (Published & Stable)] AMWA AS-11 UK DPP HD MXF Program Contribution - UK DPP HD

About this web page

AS-11: Media Contribution File Formats

Purpose of the AS-11 UK DPP HD Specification

Aims

Some notes on practical use

Understanding the Specification Blocks Tree

The Rules-Based Specification Framework

Conformance

The Specification Blocks Tree

SMPTE Metadata Registers – Labels

Framework / Group

Properties / Elements in the Framework:

Summary view of Types defined for use by this Framework

AS_11_Captions_Type_Enum

AS_11_Audio_Track_Layout_Enum

ISO_639_2_Language_Code

Metadata Constraints as Python

SMPTE Metadata Registers – Labels

Framework / Group

Properties / Elements in the Framework:

Summary view of Types defined for use by this Framework

AS_11_Captions_Type_Enum

ISO_639_2_Language_Code

UKDPP_PSE_Pass_Enum

UKDPP_Signing_Present_Enum

UKDPP_3D_Type_Enum

UKDPP_Audio_Loudness_Standard_Enum

UKDPP_Audio_Description_Type_Enum

UKDPP_Sign_Language_Enum

Metadata Constraints as Python

SMPTE Metadata Registers – Labels

Framework / Group

Properties / Elements in the Framework:

Use of Dolby E Audio Metadata Serial Bitstream Carriage

SDID value

DID value

Packets are not constant throughout

Other data being carried in the ANC Frame Element

Metadata Constraints as Python

Metadata Constraints as Python

Metadata Constraints as Python

Table of Terms

Table of References

Metadata Constraints as Python Artefacts: Specification Format Definition

Data Types

UTF16String

Integers

Booleans

Record Types

Enumerations

Helper Functions

[Specification (Published & Stable)] AMWA AS-11 UK DPP HD
MXF Program Contribution - UK DPP HD