SMPTE ST 385-2012 Material Exchange Format (MXF) - Mapping SDTI-CP Essence and Metadata into the MXF Generic Container.pdf

《SMPTE ST 385-2012 Material Exchange Format (MXF) - Mapping SDTI-CP Essence and Metadata into the MXF Generic Container.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 385-2012 Material Exchange Format (MXF) - Mapping SDTI-CP Essence and Metadata into the MXF Generic Container.pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、 Copyright 2012 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker, White Plains, NY 10601 (914) 761-1100 Approved June 5, 2012 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction . 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3 4 Glossary of

2、 Acronyms, Terms and Data Types . 4 4.1 Acronyms used in this Standard . 4 4.2 Terms used in this Standard . 4 5 SDTI-CP Compatible System Item 4 5.1 System Item Elements 4 5.2 System Metadata Pack . 5 5.3 System Item Relationship to the MXF Header Metadata 10 6 Mapping the SDTI-CP System Item to th

3、e MXF Generic Container 11 6.1 System Item Mapping . 12 7 Mapping SDTI-CP Picture, Sound and Auxiliary Items to the MXF Generic Container. 13 7.1 Picture, Sound and Auxiliary Item Mapping Details . 13 7.2 Essence Element Mapping 14 8 Length Conversions . 15 Annex A Bibliography 16 Page 1 of 16 pages

4、 SMPTE ST 385:2012 Revision of SMPTE 385M-2004 SMPTE STANDARD Material Exchange Format (MXF) Mapping SDTI-CP Essence and Metadata into the MXF Generic Container SMPTE ST 385:2012 Page 2 of 16 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recogniz

5、ed 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, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTEs Technology Comm

6、ittees. 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 Part XIII of its Operati

7、ons Manual. SMPTE ST 385 was prepared by Technology Committee 31FS. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Standard. However, attention is drawn to the possibility that some of the elements

8、of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction This section is entirely informative and does not form an integral part of this Engineering Document. The MXF Generic Container is a stream-able data

9、container structure that can be placed on any suitable transport and potentially stored. The concept of this container was based on the work done by the EBU/SMPTE Task Force in the Wrappers and Metadata subgroup. In March 1998, a SMPTE ad-hoc group was formed to study the Content Package (CP) format

10、 based on an initial strawman proposal. The CP format was developed from the ground up to carry picture, sound and data essence together with metadata in a structured manner primarily over the SDTI (SMPTE ST 305) transport and is known as SDTI-CP. SDTI-CP comprises two SMPTE engineering documents: S

11、MPTE ST 326 (SDTI-CP format) which defines the container format as applied to the SDTI; and SMPTE ST 331 (SDTI-CP element and metadata definitions) which defines the data that can be placed into the SDTI-CP container. The MXF Generic Container is an abstraction of the CP data structure that can be m

12、ade fully compatible with SDTI-CP by using the System Item data defined in this standard together with the appropriate essence mapping document where it is compliant to SMPTE ST 331. This standard specifies a version of the System Item in the MXF Generic Container that is compatible with SMPTE ST 32

13、6 noting that Auxiliary Items and elements in SMPTE ST 326 are synonymous with data items and elements in the MXF Generic Container. This standard also specifies how to map SMPTE ST 331 SDTI-CP elements and items into the MXF Generic Container. Note that in tables within this standard, some properti

14、es are SMPTE Universal Labels (ULs). A list of appropriate values for these properties is provided in SMPTE RP 224. SMPTE ST 385:2012 Page 3 of 16 pages 1 Scope This standard specifies the mapping of essence and metadata conforming to SMPTE ST 326 to the MXF Generic Container. The MXF Generic Contai

15、ner is the native Essence Container for use in an MXF file body. This standard specifies an SDTI-CP compatible System Item as a sequence of metadata elements in the MXF Generic Container. The standard then describes how the SDTI-CP System Item, conforming to SMPTE ST 326, can be mapped into the SDTI

16、-CP compatible System Item of the MXF Generic Container as defined by both SMPTE ST 379-1 and SMPTE ST 379-2. This standard also specifies how SDTI-CP picture, sound and Auxiliary Items conforming to SMPTE ST 326 can be mapped into the MXF Generic Container. This includes mapping of SDTI-CP elements

17、 conforming to SMPTE ST 326. Where required, this standard also defines how the MXF Generic Container containing the appropriate metadata and Essence Elements can be mapped into SMPTE ST 326. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable o

18、r 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

19、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 docu

20、ment 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 tha

21、t (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

22、 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,

23、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: Nor

24、mative 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 Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 326:2000) alth

25、ough, during a transitional phase, the document as published (printed or PDF) may bear an older designation (such as SMPTE 326M-2000). Documents with the same root number (e.g. 326) and publication year (e.g. 2000) are functionally identical. SMPTE ST 385:2012 Page 4 of 16 pages The following standa

26、rds contain provisions which, through 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

27、 applying the most recent editions of the standards indicated below. SMPTE ST 326:2000, Television SDTI Content Package Format (SDTI-CP) SMPTE ST 331:2011, Element and Metadata Definitions for the SDTI-CP SMPTE ST 336:2007, Data Encoding Protocol Using Key-Length-Value SMPTE ST 377-1:2011, Material

28、Exchange File (MXF) File Format Specification SMPTE ST 379-1:2009, Material Exchange File (MXF) MXF Generic Container SMPTE ST 379-2:2010, Material Exchange File (MXF) MXF Constrained Generic Container 4 Glossary of Acronyms, Terms and Data Types The general glossary of acronyms, terms and data type

29、s used in the MXF specification is given in SMPTE ST 377-1. Supplementary glossaries of terms and acronyms used in the Generic Container are given in SMPTE ST 379-1 and SMPTE ST 379-2. They are not repeated here to avoid any divergence of meaning. 4.1 Acronyms used in this Standard SMB: System Metad

30、ata bitmap CPR: Content Package rate CPT: Content Package type CH: Channel handle CC: Continuity count 4.2 Terms used in this Standard Little-endian: Any multi-byte value with the least significant byte first. 5 SDTI-CP Compatible System Item The SDTI-CP compatible System Item contains metadata whic

31、h describes the operation of the Content Package in various modes and provides key metadata items related to the whole package. It can include metadata linked to Essence Elements in the picture, sound and data items. Finally, the SDTI-CP compatible System Item includes an optional downstream control

32、 element for future possible extension. This section defines the data structure of the SDTI-CP compatible System Item. The SDTI-CP compatible System Item shall be a combination of fixed-length pack data and local set data elements, KLV coded according to SMPTE ST 336. Throughout the remainder of thi

33、s document, the SDTI-CP compatible System Item will be called simply the “System Item”. 5.1 System Item Elements The System Item shall be coded as a sequence of up to six KLV packets where each packet comprises metadata elements for different aspects of the Content Package. Figure 1 illustrates the

34、System Item data structure. SMPTE ST 385:2012 Page 5 of 16 pages Control Element Package Metadata Picture Metadata Sound Metadata Data Metadata SMPTE Universal Label Package Creation Date/ Time Stamp User Date/ Time Stamp S M B C P R C P T C H C C Package Metadata Set Picture Metadata Set Sound Meta

35、data Set Data Metadata Set Control Data Set System Metadata Pack System Item Figure 1 Elements of the SDTI-CP compatible System Item This System Item shall be divided into the following elements according to Figure 1: A System Metadata pack comprising a first 7 bytes and up to 50 further bytes (as d

36、efined by the first byte of the pack). A package metadata set that provides metadata for all Essence Elements in the Content Package. A picture metadata set that provides metadata for any Essence Element in the Picture Item. The set includes identification to link the metadata item to a specific Ess

37、ence Element in the Picture Item. A sound metadata set that provides metadata for any Essence Element in the Sound Item. The set includes identification to link the metadata items to a specific Essence Element in the Sound Item. A data metadata set that provides metadata for any Essence Element in t

38、he data item. The set includes identification to link the metadata items to a specific Essence Element in the data item. A control data set comprising of only one data item that defines a downstream control element for the Content Package. Where the System Metadata pack is present in the MXF Generic

39、 Container it shall be the first KLV packet in every Content Package. As defined in SMPTE ST 326, the Content Package metadata set immediately follows the System Metadata pack. If there are no items of Content Package metadata, then the length field of the packet shall be zero. Also per SMPTE ST 326

40、, the possible presence of each of the picture, sound and data metadata sets and the control data set is determined by bits b3 to b0 of the first byte of the System Metadata pack. Where present, the order of the picture, sound and data metadata sets shall be the same as the order of the picture, sou

41、nd and data items in the MXF Generic Container. Where present, the control data set shall be the last KLV packet of this System Item. There shall be a maximum of one system, package, picture, sound, data or control set/pack in any CP-compatible System Item. 5.2 System Metadata Pack Figure 2 illustra

42、tes the first 7 data words of the System Metadata pack. SMPTE ST 385:2012 Page 6 of 16 pages System Metadata Pack Key (16 bytes) System Metadata Pack Length (4 bytes) System Metadata Bitmap SMPTE UniversalLabelPackage Creation Date/ Time Stamp User Date/ Time Stamp b7 - FEC Active b6 - SMPTE Label b

43、5 - Creation Date/Time b4 - User Date/Time b3 - Picture Item b2 - Sound Item b1 - Data Item b0 - Control Element Content Package Rate b7 - Reserved b6 but not defined b5 b4 b3 - Package Rate b2 b1 b0 - 1.001 Flag Content Package Type b7 b6 - Stream Status b5 b4 - Sub-package flag b3 - Transfer Mode

44、b2 b1 - Timing Mode b0 Channel Handle H15 H7 H14 H6 H13 H5 H12 H4 H11 H3 H10 H2 H9 H1 H8 H0 Continuity Count C15 C7 C14 C6 C13 C5 C12 C4 C11 C3 C10 C2 C9 C1 C8 C0 S M B C P R C P T C H C C Figure 2 System Metadata pack structure 5.2.1 System Metadata pack key The System Metadata pack key shall be as

45、 defined in Table 1. Table 1 Specification of the key for the system metadata pack Byte No. Description Value (hex) Meaning 1 Object Identifier 06h 2 Label size 0Eh3 Designator 2Bh ISO, ORG 4 Designator 34h SMPTE 5 Registry Category Designator 02h Sets A Content Package rate word (1 byte); A Content

46、 Package type word, including stream status flags (1 byte); A channel handle word (2 bytes); A continuity count word (2 bytes); A SMPTE Universal Label (16 bytes); A creation date/time stamp (17 bytes); and A user date/time stamp (17 bytes). These component parts are briefly described in the followi

47、ng paragraphs. The full description of each component part can be found in SMPTE ST 326. The first component fields of the System Metadata pack shall be completed as follows: 5.2.3.1 Core fields System Metadata bitmap: b7 = 0 (FEC not used), b6 = 1 (SMPTE Universal Label is present, see below) b5 =

48、1 (creation date/time stamp is present) Note 1 b4 = 0 or 1 (user date/time stamp) Note 1 b3 = 0 or 1 (Picture Item present) Note 1 b2 = 0 or 1 (Sound Item present) Note 1 b1 = 0 or 1 (data item present) Note 1 b0 = 0 or 1 (control element present) Note 1 Content Package rate: shall be completed to r

49、eflect the correct value as defined in SMPTE ST 326 Content Package type Stream status = 0, or 16 as required the first value is the default Sub-package flag = 0 Transfer mode = 0 (default value) Note 2 Timing mode = 0 (default value) Note 2 Channel handle = 0 (default value) Continuity count = modulo 65536 count as per SMPTE ST 326 Note 3 Note 1: The value depends on the application specification. Note 2: These bits do no