1、 Table of Contents 1 Scope 3 2 Normative References 3 3 Overview . 3 4 Pattern Constraints . 4 4.1 General 4 4.2 Baseline Operational Pattern . 4 4.3 Additional Constraints 4 4.4 Labeling 5 5 Essence Constraints . 6 5.1 Picture 6 5.2 Sound. 6 6 Header Metadata Constraints . 6 6.1 General 6 6.2 Time
2、Code 7 6.3 Track File Identity. 7 7 Descriptive Metadata Constraints. 8 8 Other Constraints and Definitions . 8 8.1 File Names and Asset Identity . 8 8.2 Synchronization 8 9 MIME Type 8 Annex A Bibliography (Informative) 9 Page 1 of 9 pages SMPTE 429-3-2007Revision of SMPTE 429-3-2006 SMPTE STANDARD
3、 D-Cinema Packaging Sound and Picture Track File Copyright 2007 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved August 14, 2007 NOTE Reference RFC 2045 corrected to RFC 2046 in Sections 2 and 9. SMPTE 429-3-2007 Page 2 of 9 pa
4、ges 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. SMPTEs Engineering Documents, incl
5、uding Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs 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 IT
6、U. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its Administrative Practices. SMPTE Standard 429-3 was prepared by Technology Committee DC28. SMPTE 429-3-2007 Page 3 of 9 pages 1 Scope This standard specifies the common features of the format of sound an
7、d 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. Th
8、is document is an Application Specification for D-Cinema applications. It is based on the SMPTE 390M OP-ATOM standard, but is further constrained to address the needs of distribution of D-Cinema content to exhibition sites. 2 Normative References The following standards contain provisions which, thr
9、ough reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editio
10、n of the standards indicated below. SMPTE 330M-2004, Television Unique Material Identifier (UMID) SMPTE 377M-2004, Television Material Exchange Format (MXF) File Format Specification SMPTE 379M-2004, Television Material Exchange Format (MXF) MXF Generic Container SMPTE 390M-2004, Television Material
11、 Exchange Format (MXF) Specialized Operational Pattern “Atom“ (Simplifies Representation of a Single Item) SMPTE RP 224, SMPTE Labels Registry Internet Engineering Task Force (IETF) RFC 2046 (November 1996), Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types 3 Overview A D-Cinema So
12、und 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 SM
13、PTE 377M (MXF) and 390M (OP-ATOM). These restrictions fall in four broad categories: Pattern (in this case, a restricted version of SMPTE 390M OP-ATOM) Essence (in this case, an essence container that complies with SMPTE 379M) Header Metadata (in this case, strict compliance with SMPTE 377M) Descrip
14、tive Metadata (in this case, a small set of essential data) 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 specificati
15、on. These standards and respective combinations are beyond the scope of this standard. SMPTE 429-3-2007 Page 4 of 9 pages 4 Pattern Constraints 4.1 General D-Cinema Sound and Picture Track Files shall use the MXF file format SMPTE 377M in conjunction with the specialized Operation Pattern, OP-Atom S
16、MPTE 390M. Unless otherwise specified, Track Files shall follow the normative provisions of SMPTE 377M, SMPTE 390M and SMPTE 379M (Generic Container) and their references, notably SMPTE 336M (KLV). The full glossary of terms and acronyms used in the MXF specification is given in the MXF File Format
17、Specification. It is not repeated here to avoid any divergence of meaning. Readers unfamiliar with MXF are strongly encouraged to review the section of that document entitled “Definition of Acronyms, Terms and Data Types”. Implementers are cautioned that, although Track Files should contain only tho
18、se structures allowed by this document, SMPTE 377M nonetheless requires decoders to expect unrecognized (A.K.A. “dark”) KLV packets. Please review the section entitled “KLV Coded Dark Components” in SMPTE 377M for more information. 4.2 Baseline Operational Pattern In accordance with SMPTE 390M, each
19、 Track File shall contain one Top-level File Package, representing the Track File in its entirety, and one Material Package. The Material Package shall not be used for playback but may be used to represent the offset and duration of the portion of the track intended for reproduction. SMPTE 390M, Ann
20、ex A, gives 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. 4.3 Additional Constraints 4.3.1 Container Track Files shall use the MXF Generic Container (GC) SMPTE 379M. Track Files
21、 shall use GC frame-based essence mappings. The Sound and Picture essence mappings shall be defined by associated mapping documents. 4.3.2 Interleaving Track files shall have a single essence type within the MXF Generic Container. Essence in Track Files shall be neither interleaved1nor multiplexed b
22、etween essence types. 4.3.3 System Item The GC System Item is not used by Track Files. 4.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 Section 6.2). 1From SMPTE 377M: “multiplexed” m
23、eans 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. SMPTE 429-3-2007 Page 5 of 9 pages 4.3.5 Partitions A Track File shall have three partitions: Header, Body and
24、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 Section 4.3.6 following). When possible, Sound and other Essenc
25、e 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 377M. 4.3.6 Index Tables Track Files shall include standard MXF Index Tables per SMPTE 377M. These Index Tables shall be divided into one o
26、r more Index Table Segments. NOTE Large VBR files may require multiple Index Table Segments due to segment space limitations. See SMPTE 377M for details. Each Index Segment shall be carried in the Footer Partition. 4.3.7 KAG Size Track Files shall employ the default KLV Alignment Grid of 1 see “Key
27、Alignment Grid” in SMPTE 377M. 4.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. JPEG2000, as defined by the relevant property of the essence descriptors. 4.3.8.1 Edit Rate All essence in a Track File shall hav
28、e the same edit rate. 4.3.9 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. 4.3.10 KLV F
29、ill Track Files may use the KLV Fill item as defined in SMPTE 377M. 4.4 Labeling Track Files shall be labeled with a registered label, as per SMPTE RP 224, to identify the Essence Container and the Operational Pattern in every Partition Pack and every Preface Set. The Essence Container label shall a
30、lso be present in the File Descriptor. The Operational Pattern label shall be set according to SMPTE 390M. Since the Material Package within the Track File contains a single Source Clip (Section 4.2), Bit 0 of Byte 14 of the Operational Pattern label will always be 0. The value of Bit 1 of the same
31、byte will depend on the number of essence tracks in the Material Package. SMPTE 429-3-2007 Page 6 of 9 pages 5 Essence Constraints 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 t
32、he particular essence scheme selected. 5.1 Picture 5.1.1 General Track Files are compression-agnostic. Each Content Package of the Picture Track Files essence container shall contain one MXF GC Picture Item, each of which contains a single GC Picture Element. 5.1.2 Picture Parameters All frames in a
33、 Picture Track File shall share the same image structure. 5.1.3 Picture Packetization Picture essence shall be encoded in KLV Packets using a frame-based mapping and shall be indexed accordingly. 5.2 Sound 5.2.1 General Track Files are sound format-agnostic. Each Content Package of the Sound Track F
34、iles essence container shall contain one MXF GC Sound Item, each of which contains a single GC Sound Element. 5.2.2 Sound Sampling All samples within a Sound Track shall have the same sample rate and bit depth. 5.2.3 Sound Packetization Sound essence shall be encoded in KLV packets using a frame-bas
35、ed 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. 6 Header Metadata Constraints 6.1 General T
36、he MXF Header Metadata of Track Files shall conform to SMPTE 377M and shall be constrained according to SMPTE 390M. 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. SMPTE 429-3-2007 Pag
37、e 7 of 9 pages 6.2 Time Code Time code information shall be present in Track Files in compliance with the OP-ATOM specification. Time code information exists for informational purposes only and is not used by Track Files. 6.2.1 General Track Files shall contain synthetic time described by TimecodeSe
38、gments, 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 operatio
39、n 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. 6.2.2 Material Package Time Code The Time Code of Material Packages in Track Files shall consist of a single c
40、ontinuous segment. 6.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 historical2Source Package if known, else a reasonable default (see note in section 6.2.1). 6.2.4 Sou
41、rce 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 in section 6.2.1
42、). 6.3 Track File Identity 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“ for the remainder of this section). 6.3.1 Package UID Creat
43、ion Method The Package UID shall be a basic UMID per SMPTE 330M-2003, 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: a. Byte 11 of the UL portion of the UMID shall be 0fh(unidentified
44、material type). b. Byte 12 of the UL portion of the UMID shall be 20h(UUID/UL material number generation method and undefined instance number generation method). c. The three bytes of the instance number shall be 0 (zero). Package UID values generated in accordance with the normative provisions of t
45、his subsection will thus have the following contents in the first 16 bytes: 060a2b34h01010105h01010f20h13000000h. 2A historical Source Package is a header item that describes the source of the essence within a given Material Package. See SMPTE 377M for more details. SMPTE 429-3-2007 Page 8 of 9 page
46、s 6.3.2 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). 7 Descriptive Metadata Constraints The general rules for DMS (Descriptive Metadata Scheme) Frameworks are descr
47、ibed 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 377M. Track Files having descriptive metadata shall have a DM Label in the Preface Set to identify each DM scheme in use.
48、 8 Other Constraints and Definitions 8.1 File Names and Asset Identity The identity of the asset contained in the file shall be determined from the Package UID (as defined in Section 6.3.1 above) of the Top-Level File Package in the file, and not from the filename or any other environment-specific f
49、ile identifier, pointer or link. 8.2 Synchronization 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. 9 MIME Type Applications using MIME type identifiers RFC 2046 to identify the format of files shall use the MIME type application/mxf to identify files conforming to this specification. SMPTE 429-3-2007 Page 9 of 9 pages Annex A (Informative)
