1、 The attached SMPTE Engineering Document has been declared “Stable” by the controlling Technology Committee. The SMPTE Operations Manual for Standards states: A document should be stabilized if it is believed to be substantially correct, does not contain harmful or misleading recommendations, may st
2、ill be relevant to equipment or practices in use, is stable, but does not represent current technology, and need not be subject to future reviews. A Stable document shall still be made available and offered for sale by the Society, but it shall be prefaced by a cover page explaining its current stat
3、us. At any time, a Technology Committee may revise, amend, or otherwise initiate a new Project on a Stable document. A Stable document is “In Force”, and not deprecated or withdrawn. * * * * * * * * * * Note: SMPTE “Stable” documents were previously described as “Archived” and the attached document
4、may be marked as “Archived”. The status of a SMPTE document described as “Archived” is exactly as described above for a “Stable” document. Stable documents may not adhere to the latest style and format of SMPTE documents, or to current usage of normative language. Suitable care should be taken in in
5、terpretation. SMPTE STABLE DOCUMENT Copyright 2009 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue., White Plains, NY 10601 (914) 761-1100 Approved July 21, 2009 Table of Contents Page Foreword . 3 Intellectual Property 3 Introduction 3 1 Scope 4 2 Conformance Notation 4 3
6、Normative References 4 4 Glossary of Acronyms, Terms and Data Types 5 4.1 Acronyms Used in this Standard 5 4.2 Terms Used in this Standard 5 5 MXF Generic Container Format 5 5.1 Content Package 5 5.1.1 System Item . 5 5.1.2 Picture Item 6 5.1.3 Sound Item . 6 5.1.4 Data Item 6 5.1.5 Compound Item 6
7、5.2 System Metadata (Informative) 6 5.3 Content Package Structure . 7 5.4 Content Package Mappings 7 5.4.1 Frame-based mappings . 7 5.4.2 Clip-based mappings . 8 5.5 Default MXF Encoder Behavior 8 5.5.1 Multiple elements from the same track in a content package 8 5.6 KLV Coding Structure . 9 5.6.1 K
8、LV length field 9 6 System Item Coding 10 6.1 System Item Components 10 Page 1 of 16 pages SMPTE 379-1-2009 Revision of SMPTE 379M-2004 SMPTE STANDARD Material Exchange Format (MXF) MXF Generic Container SMPTE 379-1-2009 Page 2 of 16 pages 6.2 System Item Metadata Element Definitions 10 6.2.1 Pack a
9、nd set keys 10 6.2.2 Element value . 11 6.2.3 System item status . 11 6.3 Element to Track Relationship . 127 Picture, Sound, Data and Compound Item Coding . 12 7.1 Essence Element Key . 13 7.2 Essence Element Value 14 7.2.1 Picture, sound, data and compound item status 14 7.3 Element to Track Relat
10、ionship 14 8 SMPTE Label for Essence Container Identification 14 Annex A Bibliography (Informative) 16 SMPTE 379-1-2009 Page 3 of 16 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and inc
11、orporated 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 Committees. Participation in these Committees is open to all wi
12、th 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 Administrative Practices. SMPTE Standard 379-1 was prepared by Tec
13、hnology 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 of this document may be the subject of paten
14、t 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 streamable data container that can be placed on any suitable
15、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 sub-group. The MXF generic container defined in this standard is fully compatible with the work of the EBU/SMPTE Task Force Report. The MXF generic cont
16、ainer format is intended for inclusion into a MXF (Material eXchange Format) file as an essence container. This standard defines the MXF generic container for use in an MXF file body. The premise for the MXF generic container format is that of a general purpose essence data and metadata container fo
17、r the containment of many different kinds of essence and metadata elements into a single entity by interleaving the data streams in a defined and time-synchronous manner (typically over a 1-frame duration). Associated SMPTE mapping documents define the essence data and metadata elements that can be
18、placed in the generic container. Some mapping documents define complete mappings for an entire content package while others simply define mapping of metadata or essence data into an element. A streamable data container is designed to allow the audio-visual material to be continuously decoded through
19、 mechanisms such as interleaving essence components with stream-based metadata. The EBU/SMPTE Task Force report defines: “Content is composed of content packages, which in turn are composed of content items, which are further composed of content elements”. These content packages are convenient group
20、ings of the various Items where each Item is a group of similar element types. Although the term “content package” is also used in the SDTI-CP specification, the generic container content package is a more generalized arrangement that retains backwards compatibility with the SDTI-CP content package.
21、 SMPTE 379-1-2009 Page 4 of 16 pages 1 Scope This standard specifies the format of the MXF generic container. The MXF generic container is the native essence container of the material exchange format (MXF) file body. The MXF generic container is defined for the interchange of streamable audio-visual
22、 material. This standard defines the data structure at the signal interfaces of networks or storage media. This standard does not define internal storage formats for MXF compliant devices. Appropriate essence and metadata payloads that can be mapped into the MXF generic container are defined in asso
23、ciated documents. The MXF specification includes operation pattern specifications that may define restrictions on the way in which this essence container type should be implemented. The reader is advised to carefully study the appropriate operational pattern document for compliance to a defined impl
24、ementation. 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 remov
25、ed, 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 “N
26、ote:” 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, with
27、out 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
28、 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
29、 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. 3 Normative
30、 References The following standards 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
31、to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE 336M-2007, Data Coding Protocol Using Key-Length-Value SMPTE 377-1-2009, Material Exchange Format (MXF) File Format Specification SMPTE 379-1-2009 Page 5 of 16 pages 4 Glossary of Acronyms, Ter
32、ms and Data Types The general glossary of acronyms, terms and data types used in the MXF specification is given in SMPTE 377-1. It is not repeated here to avoid any divergence of meaning. 4.1 Acronyms Used in this Standard CP: Content package a generic term for a grouping of some combination of syst
33、em, picture, sound, data and / or compound items. GC: Generic container. 4.2 Terms Used in this Standard Picture essence: A general term for all types of picture essence including video, still images, graphics, etc. Sound essence: A general term for all types of sound essence including audio, MIDI,
34、sampled data, etc. Data essence: A general term for all types of data essence including tele-text, closed caption data, etc. Compound essence: A general term for essence that contains an indivisible mixture of different essence types. 5 MXF Generic Container Format The MXF generic container shall co
35、mprise a contiguous sequence of one or more content packages as illustrated in Figure 1. The content packages may be of constant or variable length depending on the application. The example in Figure 1 shows a generic container with content packages of variable length. Sequence start CP0 CP1 CP2 CP3
36、 CP4 CP5 CP6 CP7 CP8 CP9 CP10 CP11 Sequence end Figure 1 Generic container as a contiguous sequence of content packages 5.1 Content Package Each content package represents the essence and metadata elements interleaved over a defined duration (typically 1 picture frame) and shall be constructed of up
37、 to five Items which are the system, picture, sound, data and compound items. 5.1.1 System Item A group of up to 127 metadata or control data elements related to the container itself may be related to the elements in the other four items below. SMPTE 379-1-2009 Page 6 of 16 pages 5.1.2 Picture Item
38、A group of up to 127 picture essence elements. Each essence element in a picture item should contain a predominance of picture essence although the element may contain metadata and other ancillary essence. 5.1.3 Sound Item A group of up to 127 sound essence elements. Each essence element in a sound
39、item should contain a predominance of sound essence although the element may contain metadata and other ancillary essence. 5.1.4 Data Item A group of up to 127 data essence elements. Each essence element in a data item should contain a predominance of data essence although the element may contain me
40、tadata and other ancillary essence. 5.1.5 Compound Item A group of up to 127 compound essence elements. Each essence element in a compound Item should contain a mixture of essentially indivisible essence and metadata components that, as a group, do not match the intent of the picture, sound or data
41、items. Picture and sound items are essentially carrying the primary video and audio elements that are often routed to specialist storage or processing equipment. The data item is used to carry data-centric elements such as sub-titles and teletext data and is frequently created, processed and stored
42、on computer media. The system item provides services for each content package through metadata elements such as time stamps, metadata for essence elements in the other Items and, optionally, downstream control data elements. All Items in the MXF generic package are optional and their presence depend
43、s on the requirements of the associated mapping document. It is a key feature that each content package shall contain the associated contents of one defined duration starting with a system item (where present) and optionally containing picture, sound, data or compound items. Figure 2 shows the layer
44、ed structure of each generic container content package. System element Content Package All content packages in any Generic Container should have the same number and order of elements System Item Picture Element System metadata to element linking Picture Item Sound element Sound Item Data Item Sound
45、element Sound element Data element Data element Data element System element System element Picture Element Figure 2 Logical structure of items and elements in a content package 5.2 System Metadata (Informative) The metadata contained in the system item can include local links which associate any met
46、adata item uniquely with its corresponding essence element in the same content package. In many cases, metadata is embedded into each essence element. In the case of MPEG-2, the metadata is embedded in the various headers of the MPEG-2 essence bitstream. SMPTE 379-1-2009 Page 7 of 16 pages A metadat
47、a link from the system item to an essence element provides an additional metadata resource in a content package. The system metadata can, for example, be a partial or whole extraction of embedded metadata extracted at the data packing process to provide quick access to key metadata without a require
48、ment to re-parse the essence bitstream. The metadata can also be temporally sensitive metadata such as time-code information or camera coordinates. 5.3 Content Package Structure There shall be only one instance of an item of any type in any one content package (i.e., you cannot have two sound items
49、in one content package). If a system item is present, then every content package should start with that system item and the package is completed with any of the other Items as needed. If a system item is not present, then the content package should comprise only one element (which may be in a picture, sound, data or compound item). In content packages with no system item, there may be no mechanism to identify the first item or element in the content package, therefore only one element is recommended. 5.4 Content Package Mappings
