SMPTE ST 429-3:2023-09
Revision of SMPTE ST 429-3:2007
SMPTE Standard

D-Cinema Packaging — Sound and Picture Track File

Approved - 2023-09-12

Table of contents🔗

  1. Foreword
  2. 1 Scope
  3. 2 Conformance
  4. 3 Normative references
  5. 4 Terms and definitions
  6. 5 Overview
  7. 6 Pattern Constraints
    1. 6.1 General
    2. 6.2 Baseline Operational Pattern
    3. 6.3 Additional Constraints
      1. 6.3.1 Container
      2. 6.3.2 Interleaving
      3. 6.3.3 System Item
      4. 6.3.4 Time Code track
      5. 6.3.5 Partitions
      6. 6.3.6 Index Tables
      7. 6.3.7 KAG Size
      8. 6.3.8 Essence Kinds
      9. 6.3.9 Edit Rate
      10. 6.3.10 Encryption
      11. 6.3.11 KLV Fill
  8. 7 Labeling
  9. 8 Essence Constraints
    1. 8.1 General
    2. 8.2 Picture
      1. 8.2.1 General
      2. 8.2.2 Picture Parameters
      3. 8.2.3 Picture Packetization
    3. 8.3 Sound
      1. 8.3.1 General
      2. 8.3.2 Sound Sampling
      3. 8.3.3 Sound Packetization
  10. 9 Header Metadata Constraints
    1. 9.1 General
    2. 9.2 Time Code
      1. 9.2.1 General
      2. 9.2.2 Material Package Time Code
      3. 9.2.3 Top-Level File Package Time Code
      4. 9.2.4 Source Package Time Code
    3. 9.3 Track File Identity
      1. 9.3.1 General
      2. 9.3.2 Package UID Creation Method
      3. 9.3.3 UUID Identity Comparison
  11. 10 Descriptive Metadata Constraints
  12. 11 Other Constraints and Definitions
    1. 11.1 File Names and Asset Identity
    2. 11.2 File Names and Asset Identity
  13. 12 Media Type
  14. Bibliography

Foreword🔗

SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.

At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights.

This document was prepared by Technology Committee 27C.

This edition:

Copyright © 2024, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.

1 Scope🔗

This standard specifies the common features of the format of sound and picture Tracks Files for distribution of D-Cinema content using the MXF file format. It defines data structures for interchange at the signal interfaces of networks or storage media, but does not define internal storage formats for compliant devices or mappings for particular essence encodings. This document is an Application Specification for D-Cinema applications. It is based on the SMPTE ST 390, but is further constrained to address the needs of distribution of D-Cinema content to exhibition sites.

2 Conformance🔗

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: the 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; then formal languages; then figures; and then any other language forms.

3 Normative references🔗

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

4 Terms and definitions🔗

For the purposes of this document, the terms and definitions given in the following documents apply:

5 Overview🔗

A D-Cinema Sound and Picture Track File is an indexed, randomly-accessible MXF container for a single clip of a single essence track. D-Cinema Sound and Picture Track Files shall not contain interleaved, multiplexed, multi-scene or multi-format essence.

This standard is implemented as a set of restrictions on SMPTE ST 377-1 that fall in broad categories:

This standard is not a complete specification of a Track File for a particular essence type. It is intended to be combined with a standard essence mapping, essence constraints and optional encryption container to form a complete specification. These standards and respective combinations are beyond the scope of this standard.

6 Pattern Constraints🔗

6.1 General🔗

D-Cinema Sound and Picture Track Files shall conform to:

Implementers are cautioned that, although Track Files should contain only those structures allowed by this document, SMPTE ST 377-1 nonetheless requires decoders to expect unrecognized KLV packets ("KLV Coded Dark Components").

6.2 Baseline Operational Pattern🔗

In accordance with SMPTE ST 390, each Track File contains one Top-level File Package, representing the Track File in its entirety, and one Material Package.

As specified in SMPTE ST 390, the Primary Package Property of the Preface Set is set to the Top-Level File Package: the Top-Level File Package specifies the output timeline of the Track File and the Material Package is therefore not used for playback.

NOTE —⁠ SMPTE ST 390 provides examples of how OP-Atom MXF files can be used including the use of the Material Package tracks, Top-level File Package tracks and any lower-level Source Package tracks.

6.3 Additional Constraints🔗

6.3.1 Container🔗

Track Files shall use the MXF Generic Container (GC) specified in SMPTE ST 379-1. Track Files shall use GC frame-based essence mappings. The Sound and Picture essence mappings shall be defined by associated mapping documents.

6.3.2 Interleaving🔗

Track files shall have a single essence type within the MXF Generic Container. Essence in Track Files shall be neither interleaved nor multiplexed between essence types.

NOTE —⁠ From SMPTE ST 377-1: “multiplexed” means putting different partitions one after the other whereas "interleaved" means that the Essence Container itself has different components which are interleaved on a time division basis.

6.3.3 System Item🔗

The GC System Item is not used by Track Files.

6.3.4 Time Code track🔗

Time code tracks within the Essence Container are not used by Track Files. Synthetic time code is, however, present in the Header Metadata - (see 9.2).

6.3.5 Partitions🔗

A Track File shall have three partitions: Header, Body and Footer.The closed and complete Header Metadata shall be carried in the Header Partition, the Essence Container shall be contained in the single Body Partition and the Index Table Segment(s) shall be carried in the Footer Partition (see 6.3.6).

When possible, Sound and other Essence Partitions should have the same duration as the Picture Essence Partitions to which they relate.

Track Files shall conclude with a Random Index Pack per SMPTE ST 377-1.

6.3.6 Index Tables🔗

Track Files shall include standard MXF Index Tables per SMPTE ST 377-1. These Index Tables shall be divided into one or more Index Table Segments.

NOTE —⁠ Large VBR files can require multiple Index Table Segments due to segment space limitations. See SMPTE ST 377-1 for details.

Each Index Segment shall be carried in the Footer Partition.

6.3.7 KAG Size🔗

Track Files shall employ the default KLV Alignment Grid of 1 — see SMPTE ST 377-1.

6.3.8 Essence Kinds🔗

Within a Track File, all Essence Containers of the same kind (Picture or Sound) shall be of the same essence type, e.g. JPEG 2000, as defined by the relevant property of the essence descriptors.

6.3.9 Edit Rate🔗

All essence in a Track File shall have the same edit rate.

6.3.10 Encryption🔗

Track Files may include Essence Containers that have been subject to an encryption process. The Essence Container shall identify that the essence has been encrypted, but the definition of the encryption process is beyond the scope of this standard.

6.3.11 KLV Fill🔗

Track Files may use the KLV Fill item as defined in SMPTE ST 377-1.

7 Labeling🔗

Track Files shall be labeled with a label, registered in SMPTE ST 2123, to identify the Essence Container and the Operational Pattern in every Partition Pack and every Preface Set. The Essence Container label shall also be present in the File Descriptor. The Operational Pattern label shall be set according to SMPTE ST 390. Since the Material Package within the Track File contains a single Source Clip (see 5.2), Bit 0 of Byte 14 of the Operational Pattern label will always be 0. The value of Bit 1 of the same byte will depend on the number of essence tracks in the Material Package.

8 Essence Constraints🔗

8.1 General🔗

The Track Files support a wide range of picture and sound essence schemes and are, for instance, compression-agnostic. The following constraints exist independently of the particular essence scheme selected.

8.2 Picture🔗

8.2.1 General🔗

Track Files are compression-agnostic.

Each Content Package of the Picture Track File's essence container shall contain one MXF GC Picture Item, each of which contains a single GC Picture Element.

8.2.2 Picture Parameters🔗

All frames in a Picture Track File shall share the same image structure.

8.2.3 Picture Packetization🔗

Picture essence shall be encoded in KLV Packets using a frame-based mapping and shall be indexed accordingly.

8.3 Sound🔗

8.3.1 General🔗

Track Files are sound format-agnostic.

Each Content Package of the Sound Track File's essence container shall contain one MXF GC Sound Item, each of which contains a single GC Sound Element.

8.3.2 Sound Sampling🔗

All samples within a Sound Track shall have the same sample rate and bit depth.

8.3.3 Sound Packetization🔗

Sound essence shall be encoded in KLV packets using a frame-based mapping and shall be indexed accordingly. Where the soundtrack is multi-channel (for example, a 16 channel theatrical format), the channels should be packed at the sample level or otherwise encoded for simultaneous reproduction from a single Track File.

9 Header Metadata Constraints🔗

9.1 General🔗

Files shall be Closed and Complete.

Header Metadata shall only be present in the Header Partition. No other Partitions shall contain copies of the Header Metadata.

9.2 Time Code🔗

9.2.1 General🔗

Time code information is present in Track Files as specified in SMPTE ST 390. Time code information exists for informational purposes only and is not used by Track Files.

Track Files shall contain synthetic time described by TimecodeSegments, i.e. continuously incrementing numbers from a specified starting point. Track Files shall not contain TimecodeStream data partitions.

NOTE —⁠ Because the use of the Time Code Track(s) is specifically disclaimed above, the actual value of the starting address is not important for proper operation according to this specification. It is customary to use a default starting time of 01:00:00:00 whenever a specific value is not provided by the source essence or local operating practice.

9.2.2 Material Package Time Code🔗

The Time Code of Material Packages in Track Files shall consist of a single continuous segment.

9.2.3 Top-Level File Package Time Code🔗

The Time Code of the File Package in a Track File shall consist of a single continuous segment, with a starting time that matches that of any historical Source Package if known, else a reasonable default (see note at 9.2.1).

NOTE —⁠ A historical Source Package is a header item that describes the source of the essence within a given Material Package. See SMPTE ST 377-1 for more details.

9.2.4 Source Package Time Code🔗

Where present, the Time Code of each historical Source Package in a Track File shall consist of a single continuous segment, with a starting time that matches that of any preceding Source Package, or incoming master if known, else a reasonable default (see note at 9.2.1).

9.3 Track File Identity🔗

9.3.1 General🔗

D-Cinema Packaging uses UUID (Universally Unique Identifier) values to link assets. A Track File shall be identified by the Package UID value of its sole Top-level File Package (referred to simply as Package UID in this document).

9.3.2 Package UID Creation Method🔗

The Package UID shall be a basic UMID per SMPTE ST 330, having a UUID value in the material number part and a material number generation method of UUID/UL. The Package UID value shall be further constrained as follows:

  • Byte 11 of the UL portion of the UMID shall be 0fh (unidentified material type).
  • Byte 12 of the UL portion of the UMID shall be 20h (UUID/UL material number generation method and undefined instance number generation method).
  • The three bytes of the instance number shall be 0 (zero).

Package UID values generated in accordance with the normative provisions of this sub-clause will thus have the following contents in the first 16 bytes:06.0a.2b.34.01.01.01.05.01.01.0f.20.13.00.00.00.

9.3.3 UUID Identity Comparison🔗

When testing a Track File for identity against a known UUID, the known UUID shall be compared to the material number part of the Package UID (bytes 17-32).

10 Descriptive Metadata Constraints🔗

The general rules for DMS (Descriptive Metadata Scheme) Frameworks are described in SMPTE EG 42. Optional descriptive metadata, where present, shall be carried in Track Files in a DM (Descriptive Metadata) Segment of a Static DM Track as defined by SMPTE ST 377-1. Track Files having descriptive metadata shall have a DM Label in the Preface Set to identify each DM scheme in use.

11 Other Constraints and Definitions🔗

11.1 File Names and Asset Identity🔗

The identity of the asset contained in the file shall be determined from the Package UID of the Top-Level File Package in the file, and not from the filename or any other environment-specific file identifier, pointer or link.

11.2 File Names and Asset Identity🔗

Methods for synchronizing two or more Track Files having the same or differing essence types are beyond the scope of this document. Track Files shall not be required to contain synchronization information other than that provided by the MXF Header Metadata.

12 Media Type🔗

Applications using media types as specified in IETF RFC 6838 to identify the format of files shall use the media type application/mxf to identify files conforming to this specification.

Bibliography🔗