SMPTE ST 379-2-2010 for Television Material Exchange Format (MXF) MXF Constrained Generic Container《电视 素材交换格式(MXF) MXF约束普通容器》.pdf

《SMPTE ST 379-2-2010 for Television Material Exchange Format (MXF) MXF Constrained Generic Container《电视 素材交换格式(MXF) MXF约束普通容器》.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 379-2-2010 for Television Material Exchange Format (MXF) MXF Constrained Generic Container《电视 素材交换格式(MXF) MXF约束普通容器》.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

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

2、Terms and Data Types 4 5 Overview . 4 6 Legacy Considerations (Informative) . 5 7 MXF Container Constraints Signaling . 5 8 MXF Generic Container Format 6 9 System Item Coding 14 10 Picture, Sound, Data and Compound Item Coding 17 11 SMPTE Essence Container Label . 19 Annex A Bibliography (Informati

3、ve) . 20 Page 1 of 20 pages SMPTE ST 379-2:2010 SMPTE STANDARD for Television Material Exchange Format (MXF) MXF Constrained Generic Container SMPTE ST 379-2:2010 Page 2 of 20 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards dev

4、eloping 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 Committees. Particip

5、ation 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 Administrative Practice

6、s. SMPTE ST 379-2 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 of this

7、 document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. SMPTE ST 379-2:2010 Page 3 of 20 pages 1 Scope This standard specifies numerous refinements based on SMPTE 379-1. This standard specifies the format of the MXF Generic Co

8、ntainer (GC). The MXF GC is the native essence container of the material exchange format (MXF) file body. The MXF GC is defined for the interchange of streamable audio-visual material. This standard defines the data structure at the signal interfaces of networks or storage media. This standard does

9、not define internal storage formats for MXF compliant devices. Appropriate essence and metadata payloads that can be mapped into the MXF GC are defined in associated documents The MXF specification includes operation pattern specifications that may define restrictions on the way in which this essenc

10、e container type should be implemented. The reader is advised to carefully study the appropriate operational pattern document for compliance to a defined implementation. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conform

11、ance 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

12、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

13、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

14、) 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

15、 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 (“

16、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 aut

17、horitative 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 standard. At the time of publication, the

18、 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 of the standards indicated below. SMPTE 331M-2004, Television Element and Metadata Definitions for the SDTI

19、-CP SMPTE 336M-2007, Data Coding Protocol Using Key-Length-Value SMPTE 377-1-2009, Material Exchange Format (MXF) File Format Specification SMPTE ST 379-2:2010 Page 4 of 20 pages 4 Glossary of Acronyms, Terms and Data Types The general glossary of acronyms, terms and data types used in the MXF speci

20、fication is given in SMPTE 377-1. Most definitions are not repeated here to minimize any divergence of meaning. 4.1 Acronyms Used in this Standard CI: Content Item a unit that consists of one or more Content Elements. CE: Content Element a single KLV element of any kind belonging to a Content Item.

21、CP: Content Package a generic term for a grouping of some combination of System, Picture, Sound, Data and / or Compound Items. GC: Generic container. GOP: Group of pictures, as used in ISO/IEC 13818-2. KLV: Key-Length-Value, defined in SMPTE 336M. 4.2 Terms Used in this Standard Picture Essence: A g

22、eneral 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, sampled data, etc. Data Essence: A general term for all types of Data Essence including teletext, closed caption data, etc. C

23、ompound Essence: A general term for essence that contains an indivisible mixture of different essence types. Essence Element: The entire essence stream of a single track wrapped by one or more Content Elements, depending on the wrapping type. 5 Overview The MXF Generic Container (GC) is a streamable

24、 data container 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 sub-group. The MXF GC defined in this standard is fully compatible with the work of the EBU/SMPTE Tas

25、k Force Report. The MXF GC format is intended for inclusion into a MXF (Material eXchange Format) file as an essence container. This standard defines the MXF GC for use in an MXF file body. Notes: 1 A streamable data container is designed to allow the audio-visual material to be continuously decoded

26、 through mechanisms such as interleaving essence components with stream-based metadata. 2 The 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 groupi

27、ngs 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 GC Content Package is a more generalized arrangement that retains backwards compatibility with the SDTI-CP Content Package. The MXF GC compri

28、ses a contiguous sequence of Content Packages, each of which has up to five basic components known generically as Content Items, and more specifically known as one of the following: A System Item is a group of up to 127 metadata or Control Data Elements. The metadata contained in the System Item can

29、 include local links which associate any metadata item uniquely with its corresponding Content Element. In many cases, metadata can be embedded into each Content SMPTE ST 379-2:2010 Page 5 of 20 pages Element. In the case of MPEG-2, the metadata can be embedded in the various headers of the MPEG-2 e

30、ssence bitstream). The metadata link from the System Item to a Content Element provides metadata in addition to the essence bitstream. The system metadata can be a partial or whole extraction of embedded metadata extracted at the data packing process to provide quick access to key metadata without a

31、 requirement to re-parse the essence bitstream. The metadata can also be temporally sensitive metadata such as time-code information or camera coordinates. A Picture Item is a group of up to 127 Picture Content Elements. Each Content Element in a Picture Item contains a predominance of picture essen

32、ce although the element could contain metadata and other ancillary essence. A Sound Item is a group of up to 127 Sound Content Elements. Each Content Element in a Sound Item contains a predominance of sound essence although the element could contain metadata and other ancillary essence. A Data Item

33、is a group of up to 127 Data Content Elements. Each Content Element in a Data Item contains a predominance of data essence although the element could contain metadata and other ancillary essence. A Compound Item is a group of up to 127 Compound Content Elements. Each Content Element in a Compound It

34、em contains a mixture of essentially indivisible essence and metadata components that, as a group, do not match the intent of the Picture, Sound or Data Items. Picture, Sound and Compound Items are essentially carrying the primary Video and Audio Elements that are often routed to specialist storage

35、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 on computer media. The System Item provides services for each Content Package (CP) through Metadata Elements such as time stamps, metadat

36、a for Content Elements in the other Items and, optionally, downstream Control Data Elements. The premise for the MXF GC format is that of a general purpose Essence and Metadata container for the containment of many different kinds of Essence and Metadata Elements into a single entity by interleaving

37、 the data streams in a defined and time-synchronous manner (typically over a 1-frame duration). Associated SMPTE GC mapping documents define the Essence and Metadata Elements that can be placed in the container. Some SMPTE GC mapping documents could define complete mappings for an entire Content Pac

38、kage while others could simply define mapping of Metadata or Essence into an element. The MXF GC defined by this document complies with the requirements for essence containers defined in the MXF file format specification. 6 Legacy Considerations (Informative) SMPTE ST 379-2 is intended to be a prope

39、r subset of SMPTE 379-1. In some cases, the scope of SMPTE 379-1 allows greater latitude by leaving constraints unspecified. This version is generally consistent with SMPTE 379-1, but includes additional constraints with the objective of permitting simpler implementation of compliant decoders. 7 MXF

40、 Container Constraints Signaling Encoders that conform to this specification shall add a ContainerConstraintSubDescriptor to the GenericDescriptor:SubDescriptors property of the top-most File Descriptor that describes the essence container. SMPTE ST 379-2:2010 Page 6 of 20 pages The GenericDescripto

41、r:SubDescriptors is defined by SMPTE 377-1, Annex B.2: Element Name Type Len Local Tag UL Designator Req? Element Description All elements from the Generic Descriptor defined in SMPTE 377M-1, Annex B.2 Sub Descriptors StrongRefArray (Sub Descriptors) 8+16n Dyn 06.0e.2b.34 01.01.01.09 06.01.01.04 06.

42、10.00.00 Opt Ordered array of strong references to sub descriptor sets The set Key of the ContainerConstraintsSubDescriptor shall be as defined in the table below. Byte No. Description Value Meaning 113 As defined in SMPTE 377-1, Table 18 Values for all MXF structural metadata sets 1415 Set Kind 01.

43、67h Defines the Key value for the Container Constraints Sub Descriptor 16 Reserved 00h Reserved value The Container ConstraintsSubDescriptor does not define any required properties in addition to those inherited from the Generic SubDescriptor. Item Name Type Len Local Tag Item UL Req ? Meaning Conta

44、iner Constraints SubDescriptor Group UL 16 As defined in SMPTE 377-1, Annex B.3 Req Defines the Container Constraints SubDescriptor Class All items in SMPTE 377-1, Annex B.3 except the Key or Group UL and the Length, if present See SMPTE 377-1, Annex B.3 8 MXF Generic Container Format The MXF Generi

45、c Container (GC) comprises a contiguous sequence of one or more Content Packages (CP) as illustrated in Figure 1. The CPs may be of constant or variable length depending on the application. The example in Figure 1 shows a GC with Content Packages of variable length. S e q u e n c e s t a r t C P 0 C

46、 P 1 C P 2 C P 3 C P 4 C P 5 C P 6 C P 7 C P 8 C P 9 C P 1 0 C P 1 1 S e q u e n c e e n d Figure 1 GC as a contiguous sequence of CPs SMPTE ST 379-2:2010 Page 7 of 20 pages 8.1 Content Package Definition A Content Package (CP) shall consist of a collection of one or more Content Items (CI). A CI sh

47、all consist of one or more Content Elements (CE). A CE shall consist of zero or more pieces of the Essence Element, one Metadata or System Element or one of any other kind of element. A CP may include Metadata directly related to the CP itself, or used to associate the component parts (CIs and CEs).

48、 A CP may be a complex audiovisual sequence video, audio, subtitles and description; or it could be as simple as a single frame of video with or without the associated audio. CP instances support mutual synchronization of multiple CIs. In the context of this document, CP instances shall be encoded a

49、s an ordered sequence of KLV packets of CEs and, optionally, a KLV Fill item to form the byte stream of the essence container. Depending on the duration of the CP instances and the number of CP instances in the essence container, this document distinguishes three different encoded CP representations: frame wrapped, clip wrapped and custom wrapped. In frame wrapped CP representations, the duration of a CP shall equal the duration of a frame or field. If no Picture Item is present in the CP, and