MRX container specification
SPECIFICATION
Version 0.201
Release Date: 2023-04-25 00:00:00 +0000 UTC. Send comments via the contact form
Authors
Bruce Devlin (Mr. MXF, metarex.media, SMPTE)
Original Authors
ARRI GmbH: Wolfgang Wegner, Hermann Popp
Nablet GmbH: Peter Neumann
Fusion Media: Kevin Burrows
Bruce Devlin (Mr. MXF, SMPTE)
Version History
| Version | Author | Change Note |
|---|---|---|
| 2022-11-22 | Devlin | Refactored to HTML for launching MetaRex |
| 2019-04-15 | Wegner | (MXF Live DM Spec) Removed indirect Link to DM set, added Streaming Mode |
| 2019-04-10 | Neumann | (MXF Live Streaming Spec) Refined Streaming Modes |
| 2019-02-19 | Wegner | (MXF Live DM Spec) Integrated first comments by Peter Neumann |
| 2019-02-15 | Wegner | Initial Version of MXF Live DM Spec |
| 2019-02-08 | Neumann | (MXF Live Streaming Spec) Add Streaming Mode definitions |
| 2019-01-10 | Neumann | Initial MXF Live Streaming Spec Outline |
Table of Contents
5.1.1 Basic Stream Structure Constraints
5.1.2 MXF Live Streaming Modes
5.1.3 Multiple linked MXF Live streams
5.2.1 Receiver for Continuous Stream
5.2.2 Receiver for Continuous Segmented Stream and Intermittent Segmented Stream
6 MXF Live Descriptive Metadata
6.3 Specification of Sets, Descriptors and Properties
6.3.1 MXF Live Streaming Specific Descriptive Metadata Framework Set
1 Scope
This document specifies constraints for an MXF Live Streaming format and a method for mapping of metadata related to MXF Live streaming into a DM Framework static track within an MXF Generic Container.
2 Conformance Notation
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: Introduction, any section explicitly labeled as "Informative" or individual paragraphs that start with "Note:"
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future.
A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms.
3 Normative References
The following standards contain provisions which, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below.
SMPTE ST 377-1:2011 – Material Exchange Format (MXF) – File Format Specification
SMPTE ST 378:2004 – Material Exchange Format (MXF) – Operational Pattern 1a
SMPTE ST 379-2:2010 – Material Exchange Format (MXF) – MXF Generic Container
SMPTE ST 2049:2012 - Low Latency Streaming MXF Op1a
SMPTE ST 326:2000 – SDTI Content Package Format (SDTI-CP)
SMPTE ST 331:2011 – Element and Metadata Definitions for the SDTI-CP
SMPTE ST 382:2007 – Material Exchange Format (MXF) – Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container
SMPTE ST 384:2005 – Material Exchange Format (MXF) – Mapping of Uncompressed Pictures into the Generic Container
SMPTE ST 385:2004 – Material Exchange Format (MXF) – Mapping SDTI-CP Essence and Metadata into the MXF Generic Container
SMPTE ST 394:2006 – Material Exchange Format (MXF) – System Scheme 1 for the MXF Generic Container
SMPTE ST 405:2006 – Material Exchange Format (MXF) – Elements and Individual Data Items for the MXF Generic Container System Scheme 1
SMPTE RDD 18:2012 – Acquisition Metadata Sets for Video Camera Parameters
SMPTE RP 210v13:2012 – Metadata Dictionary Registry of Metadata Element Descriptions
SMPTE RP 224v12:2011 – SMPTE Labels Register
SMPTE RP 2057:2011 – Text-Based Metadata Carriage in MXF
SMPTE EG 42:2004 Material Exchange Format (MXF) – MXF Descriptive Metadata
4 Introduction
From beginning MXF (SMPTE ST 377) was designed as a file format as well as a streaming format. MXF’s structure based on KLV elements (SMPTE ST 336) provides high flexibility.
Modern IP provides the bandwidth to transport professional media data.
Flexibility in meta data carriage is the advantage of MXF Live over any other streaming solution.
A low latency streaming MXF format is already specified in SMPTE ST 2049.
The ‘MXF Live’ streaming specification shall add extra constraints to enable a receiver of such an MXF stream to start processing or capturing it from any stream position/time, not just from the beginning of the stream.
Purpose is not only to stream MXF Live from Audio/Video devices but also from any other equipment, be it for example meta data from camera trackers, lighting equipment or directors and script comments in an on scene scenario.
A receiver of MXF Live stream may store the streams separately or merge tracks from multiple MXF Live streams into a single MXF file or a new MXF Live stream for further transmission. All on scene generated meta data is preserved centrally.
On scenarios with multiple stream sources, one MXF Live stream, typically a video stream, has to be the master or primary stream. All other streams share the same time base.
MXF Live streams may contain meta data to control recording to file on a receiver side.
The IP layer used for streaming is not in the scope of this document and subject of the user’s implementation requirements. Any protocol, from simple UDP up to RTP and ST 2110 is suitable
5 Implementation
5.1 MXF Live Encoder
5.1.1 Basic Stream Structure Constraints
SMPTE ST 2049 already defines a low latency MXF streaming. Based on this and additional constraints the general rules for an MXF Live stream are:
-
Operational Pattern 1A.
-
Duration values in Header Metadata shall be -1 except for the repeated header meta data in a footer partition. (On a stream captured to disk a receiver may update the initial header meta data however)
-
The stream shall be segmented into multiple Body Partitions for any kind of essence, be it variable or constant edit unit size.
-
Segment durations shall be from 1 to 60 seconds configurable in a granularity of ~1 second. In case the edit rate does not allow to divide the segment duration into an integer count of edit units the segment duration shall be as close as possible to the desired duration.
-
Essence Body Partitions, except the first one, shall be preceded by a Body Partition which contains the repeated header metadata. The header meta data may contain updated descriptive meta data objects. Repeated header metadata allow a decoder/receiver to join the stream at any segment.
-
Each Essence Body Partition shall be followed by a Body Partition with an Index Table segment indexing the previous essence body partition. This is mandatory also for simple index tables for constant edit unit size.
-
The Timecode Track in the repeated header meta data shall have a start time code value which matches the initial start timecode plus the essence elements count of all previous partitions to allow instant access. This allows a receiver that starts capturing on the fly to get an actual time code.
-
Header meta data shall carry a static descriptive meta data object which contains MXF Live related meta data as described in chapter 6. The MXF Live related meta data contents may vary in the repeated header meta data for example to signal the start of a segment of interest.
-
For Long GOP Video essence, the Body Partitions shall start at GOP Boundaries.
-
The Footer Partition shall repeat all index table segments and contain a RIP.
-
The Footer Partition shall repeat the header meta data but updated with final duration values. The Timecode track in that final repeated header meta data shall have the initial start value again.
5.1.2 MXF Live Streaming Modes
Different streaming modes and additional control signals allow a variety of use cases, including a remote control of an MXF Live receiver. Streaming modes and various control flags are signaled in static descriptive metadata (DM) objects which shall be carried in the repeated header metadata. The layout of those DM objects is specified later in chapter 6.
-
Continuous Streaming Mode
A device streams from power on to power off. The stream is starting with a header partition and ends with a footer partition.
In some case header and footer partition may be omitted, e.g. when it is intended that a receiver joins the stream on the fly or is merging multiple MXF Live streams which causes a re-multiplexing.
-
Continuous Segmented Streaming Mode
A device streams continuously from power on to power off, starting with a header partition, but on a certain event it finalizes the current MXF stream with a footer partition. It then starts a new stream beginning with a header partition again which grows until the next event.
An event can for example be a camera’s REC START and REC STOP.
A header partition shall carry a static meta data object as specified in chapter 6 which signals SEGMENT OF INTEREST among other live stream related meta data. Such signal can advise a specialized receiver which listens and monitors to capture this stream segment.
-
Intermittent Segmented Streaming mode (Record only mode)
A device streams only for a certain time, then there may be a break until the next segment is started. All segments may be segments of interest. E.g. a camera streams from REC START to REC STOP.
In the scope of a receiver which continuously listens, this is very similar to the Continuous Segmented Mode. It may not be able to distinguish between the two modes. Therefore, also in this mode a stream meta data object shall signal SEGMENT OF INTEREST to trigger the capturing of segments on a specialized receiver.
Typically, only a primary MXF Live stream, e.g. from a camera, may stream in segmented mode. If secondary MXF Live streams are segmented, segmentation shall be synchronized with the primary stream at the receiver side.
5.1.3 Multiple linked MXF Live streams
On Set, multiple MXF Live streams may be transmitted from different sources, to be gathered at a central receiver. In such scenario one stream, typically from a video source, shall be the master stream, ruling streaming mode and Segment of Interest flags. The master stream is signaled in the MXF Live related DM. All streams must share the same timecode. All streams must use the same edit rate.
5.2 MXF Live Decoder/Receiver
5.2.1 Receiver for Continuous Stream
A receiver which shall capture and process an incoming continuous stream from beginning (Header partition) to the end (RIP) can be simple. Capturing to file is a simple dump.
However, the structure of an MXF Live stream allows a decoder to start to decode, demultiplex or record the stream on the fly from any position or time only limited by the granularity of the partition duration. When a Body Partition with repeated header meta data has been received, all necessary information to further interpret and process the incoming KLV containers is available.
A receiver that joins a stream later than at the beginning and which wants to store the MXF stream to file must reflag/remap that first body partition to a Header partition and write it out, followed by all further KLV containers. Furthermore it may be necessary to remap index tables to match the index start values and offsets.
If a receiver that wants to stop capturing and writing while the stream is still continuing, it shall stop capturing after having received the completed body partition with the index segment of the previous essence body partition or discard any incomplete index partition. It shall then create a footer partition with all received index table segments and updated header meta data.
In a special case creation of a footer partition may be omitted and thus the file will be left in a ‘growing’ state if the decoders which shall later parse such file are able to handle growing files.
Alternatively a receiver may re-multiplex the incoming MXF Live stream into a new stream or file.
In case a receiver is merging multiple incoming MXF Live streams it would have to re-multiplex them all into a single stream anyway.
5.2.2 Receiver for Continuous Segmented Stream and Intermittent Segmented Stream
A simple Receiver which listens to and monitors segmented streams and also shall capture segments to file must start a new file for each segment, triggered by the appearance of a header partition.
A specialized receiver shall be able to read and interpret the static MXF Live descriptive meta data object present in the header partition of a segment in order know which segment is of interest and which shall be captured to file or be streamed further on or be treated differently in any other way.
If multiple MXF Live streams are to be merged, the primary stream rules the segment of interest. Secondary streams may be unsegmented.
A receiver may also be configured to ignore segment boundaries and further process all segments as a continuous stream.
6 MXF Live Descriptive Metadata
For streaming MXF content, an easy transition between streaming media and file-based storage is desired while keeping flexibility for different scenarios. Most MXF structural metadata can be used for both stream and file without modification while additional data may be useful to ease handling at the boundaries, i.e. in the stream transmitter and receiver.
Note: The UL keys used for description and coding of data are being taken from ARRI private space. While trying to establish a consistent assignment of keys within this private area, we may have failed at some point or the other. Any comments to improve consistency are welcome.
6.1 Header Metadata Mapping
Files adhering to this specification shall be compliant with the MXF Live specification, the MXF generic container and OP 1a as defined in SMPTE ST 377-1:2011, SMPTE ST 379-2:2010 and SMPTE ST 378:2004, respectively.
An additional static descriptive metadata track is added to the header metadata. The descriptive metadata framework is of type “MXF Live Streaming Descriptive Metadata” which is further described in this document. As such, the framework is referenced in the Preface Set while the track itself is referenced in the Material Package (Figure 1)
{width=“4.580555555555556in”
height=“4.434722222222222in”}
Figure 1: Linkage of MXF Live DM Track in MXF Header Data
The new keys and labels used for the descriptive metadata are taken from ARRI private space. Table 1 shows the scheme applied to make up the keys within ARRI private space whereas Table 2 lists the actual keys relevant for this specification. The definition of the MXF Live Streaming Descriptive Metadata Set is in Table 3 .
6.2 UL Keys used for Coding
Table 1 - Structure of UL Keys for this Specification
| Byte No. | Description | Value (hex) | Meaning |
|---|---|---|---|
| 1-4 | SMPTE UL Designator 06.0E.2B.34 | ||
| 5-8 | Category, Registry, Structure and Version as in ST 0336:2007 | ||
| 9,10 | 0E.17 (ARRI private range) | ||
| 11 | Item Type Identifier (resembling Byte 9 of SMPTE 359M) | 01h | Identifiers and Locators |
| 02h | Administrative Group | ||
| 03h | Interpretive Group | ||
| 04h | Parametric Group | ||
| 05h | Process and Processing Group | ||
| 06h | Relational Group | ||
| 07h | Spatio-Temporal Group | ||
| 0Ch | Compound Group | ||
| 12 | Target Identifier | 00h | General |
| 01h | Picture Essence Related | ||
| 02h | Sound Essence Related | ||
| 03h | Data Essence Related | ||
| 04h | Metadata Related | ||
| 05h | Compound (Essence) Related | ||
| 13 | Further Classification | 00h | General |
| 13 | 01h | Fundamental Parameters | |
| 02h | Coding Characteristics | ||
| 03h | Static Parameters | ||
| 04h | Dynamic Parameters | ||
| 05h | Generic Parameters (dyn. or static) | ||
| 14-15 | Further Classification | Distinction within each group | |
| 16 | Index | 00h | Index in case of more than one item of the same type, e.g. multiple data streams, or distinction within group |
Table 2 - UL Key Definitions for this Specification
| Item Name | UL Key |
|---|---|
| MXF Live Streaming Specific Descriptive Metadata Framework Label | 060e2b34.0401010d.0e170404.01010201 |
| MXF Live Streaming Specific Descriptive Metadata Framework Set | 060e2b34.0253010d.0e170104.01010201 |
| MXF Live Streaming Specific Descriptive Metadata Set (not used any more) | 060e2b34.0253010d.0e170104.01030201 |
| MXF Live Streaming KLV Object Reference (not needed any more) | 060e2b34.0101010d.0e170604.01010301 |
| MXF Live Streaming Specific Static Items | 060e2b34.0101010d.0e170104.03010000 |
| MXF Live Segment of Interest Flag | 060e2b34.0101010d.0e170104.03010101 |
| MXF Live Stream Generation Index | 060e2b34.0101010d.0e170104.03010102 |
| MXF Live Primary (Master) Stream Flag | 060e2b34.0101010d.0e170104.03010103 |
| MXF Live Streaming Mode | 060e2b34.0101010d.0e170104.03010104 |
Note: These keys are preliminary keys to be used during experimental state; they are subject to change without notice.
6.3 Specification of Sets, Descriptors and Properties
6.3.1 MXF Live Streaming Specific Descriptive Metadata Framework Set
The MXF Live Streaming Specific Descriptive Metadata Set groups all items relevant to streaming. It shall be coded as a local set using 2-byte tags and 2-byte length fields.
Table 3 – Items to be used in the MXF Live Streaming Specific Descriptive Metadata Set
| Item name | Type | Len | Local Tag | Item UL | Req? | Meaning |
|---|---|---|---|---|---|---|
| MXF Live Streaming Specific Descriptive Metadata Framework Set | Set Key | 16 | As defined in Table 2 | Req. | 060e2b34.0253010d.0e170104.01010201 Set Key to identify MXF Live Streaming Specific DM Framework Set |
|
| Length | BER Length | var. | Req. | Set Length (see ST 377-1:2011) | ||
| Instance UID as defined in ST 377-1:2011 | UUID | 16 | 3C 0A | Req. | Strong Reference from MXF Live Streaming Specific DM Framework (MXF Live Streaming KLV Object Reference) | |
| Segment of Interest Flag | Boolean | 1 | dynamic | 060e2b34. 0101010d. 0e170104. 03010101 | Opt. | Flag signaling whether the current stream segment is intended for recording (wording TBD). When set to false (0), no recording is desired. When set to true (1), the stream shall be captured, i.e. written to a file on storage media. |
| Stream Generation Index | UInt32 | 4 | dynamic | 060e2b34. 0101010d. 0e170104. 03010102 | Opt. | Index indicating whether this is a primary stream (originating from a capture device) or has already been processed. When transmitted by a capture device, the value shall be set to 0; when transmitted from a file, the value shall be set to 1. Whenever an application receives a stream and re-transmits it without storage, the value shall be incremented by 1. |
| Primary (Master) Stream Flag | Boolean | 1 | dynamic | 060e2b34. 0101010d. 0e170104. 03010103 | Opt. | Flag set in the stream by the master controlling receiver behavior. |
| Streaming Mode | UInt8 | 1 | dynamic | 060e2b34. 0101010d. 0e170104. 03010104 | Opt. | Control the receiver to enable user-defined or remote-controlled (by sender) capture. In continuous mode, a user can select which part to capture while in segmented modes, the receiver is controlled by “Segment of Interest Flag”. 0: Continuous Streaming Mode 1: Continuous Segmented Streaming Mode 2: Intermittent Segmented Streaming Mode |
7 Meta Data
As mentioned in the introduction, meta data is an important factor of MXF Live. All meta data shall always be available together with the A/V data immediately.
Therefore, static meta data tracks in the header partition shall be avoided as they would not be recognized by a receiver which joins a stream on the fly. If the data amount that such static tracks carry, it may be considered to copy this in the body partitions with the repeated header meta data. However, overhead caused by the header meta data repetition shall be kept as low as possible. Instead any meta data shall be carried in data essence tracks.
An example is SMPTE RDD-18 meta data in ANC data tracks. But the MXF Live group discussed to get rid of the ANC layer and recommends to carry RDD-18 meta data in data frame KLV containers directly only.
There is further discussion about RDD-18 UDAM extensions for additional equipment meta data. A proposal for a UDAM extension for camera tracking metadata is available and was used in MXF Live demonstrations.
Other varieties of meta data description such as RDD-47 frame-wrapped xml meta data seem to be suitable.
Generally, definitions for meta data carriage will not affect the MXF Live specification directly but constraints or recommendations to use a specific meta data wrapping style for specific kind of meta data may be added.
8 Considerations
It needs to be discussed whether MXF Live streams which carry meta data only need to be based on the same edit rate than the primary A/V stream as specified in 5.1.3, or whether they can be operated in lower edit rates, e.g. if they update their data only every second anyway. For a receiver which merges the incoming tracks from different streams then it would be necessary to repeat metadata containers in order to match the master edit rate.
Furthermore it is discussed whether MXF Live stream format could used in IMF or an IMF like structure which would be an alternative way to keep the whole bouquet of On Set generated A/V and meta data together, other than re-multiplexing the individual tracks into a single Op1a MXF file or stream.
2019.10.23
Peter Neumann
Feedback
Was this page helpful?