SMPTE ST 394M-2006 Television - Material Exchange Format (MXF) - System Scheme 1 for the MXF Generic Container.pdf

《SMPTE ST 394M-2006 Television - Material Exchange Format (MXF) - System Scheme 1 for the MXF Generic Container.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 394M-2006 Television - Material Exchange Format (MXF) - System Scheme 1 for the MXF Generic Container.pdf（7页珍藏版）》请在麦多课文档分享上搜索。

1、 1 Scope This standard specifies the data format for the System Item of the MXF Generic Container (GC) that is called System Scheme 1. This data format is a superset of the System Item defined in SMPTE 385M (Mapping SDTI-CP Essence and Metadata into the MXF Generic Container) and provides a more gen

2、eric and flexible data structure that can provide system elements for flexible GC wrappings including clip-based wrapping. This document defines the rules that System Elements in the System Item shall follow in order to be classified as a System Scheme 1 System Element. The MXF Generic Container is

3、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 material. This document defines the data structure at the signal interfaces of networks or storage media. This document does not define in

4、ternal storage formats for MXF compliant devices. 2 Normative 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

5、 parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE 336M-2001, Television Data Coding Protocol using Key-Length-Value SMPTE 377M-2004, Television Material Exchange Format (MXF) File Fo

6、rmat Specification SMPTE 379M-2004, Television Material Exchange Format (MXF) MXF Generic Container SMPTE RP 210, Metadata Dictionary Registry of Metadata Element Descriptions 3 Glossary of Acronyms, Terms and Data Types The general glossary of acronyms, terms and data types used in the MXF specific

7、ation is given in SMPTE 377M and is supplemented in SMPTE 379M. These are not repeated here to avoid any divergence of meaning. 4 Introduction The MXF Generic Container is defined in SMPTE 379M. This standard specifies a generic System Item structure that can be used to carry metadata that describes

8、 the essence elements in the Content Package. It also describes methods of wrapping the essence and metadata elements as either “Frame Wrapping” or “Clip Page 1 of 7 pages SMPTE 394M-2006 Copyright 2006 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601

9、 (914) 761-1100 Approved July 7, 2006 SMPTE STANDARD for Television Material Exchange Format (MXF) System Scheme 1 for the MXF Generic Container SMPTE 394M-2006 Page 2 of 7 pages Wrapping”. The System Item comprises a number of System Elements. Each of these System Elements contains metadata that is

10、 intimately related to essence within the same Content Package. The System Elements are not intended to carry metadata that is to be described in the MXF Header Metadata by a Track, SourceClip or Segment. Neither is it intended to carry metadata that should be carried in a non-Essence Data Partition

11、. This standard defines a generic scheme for the GC System Item that allows System Elements to be added as required by an application. SMPTE 405M defines metadata elements and individual data items that are compatible with this GC System Scheme 1. SMPTE 389M defines a System Reverse Play Element whi

12、ch is compatible with this GC System Scheme 1. SMPTE 385M defines how the System Item that is defined in SMPTE 326M (SDTI Content Package Format) can be mapped in a MXF GC System Item. SMPTE 326M is constrained to frame-based wrapping and thus the System Item mapping defined by SMPTE 385M is also li

13、mited for frame-based wrapping. This standard defines a compatible superset of the System Item defined in SMPTE 385M in that it provides a System Item that can be used with all known Generic Container wrappings including clip-wrapping. Figure 1 illustrates the use of the System Item in a Content Pac

14、kage. K LSoundElementVVK LSystemElementK LSoundElementVSoundItemSystemItem1 frame or clipK LVPictureElementVK LDataElementPictureItemVK LDataElementDataItemVK LSystemElementVK LSystemElementFigure 1 Illustration of a GC System Item in a Content Package In clip wrapping, one or more contiguous essenc

15、e frames may be wrapped within a single GC Essence Element in a GC Essence Item. Any GC System Element must be capable of carrying any stream metadata that is associated with an Essence Element in a Content Package. Some stream metadata is present on a “per frame basis” and this needs to be mapped i

16、nto a GC System Element as a vector of values corresponding to the vector of frames within a GC Essence Element. Because the System Scheme defined in this standard provides compatibility with SMPTE 385M, any elements that can be used in SMPTE 385M can also be used in the System Item defined in this

17、standard. However, this System Scheme cannot generally be used where compatibility with SMPTE 326M is required. The System Item defined in SMPTE 379M comprises a contiguous sequence of up to 127 KLV coded System Elements as illustrated in Figure 2. As in SMPTE 379M, for each Content Package, every S

18、ystem Element comprises metadata or control data that is intimately related to the Essence Elements within the same Content Package. As in SMPTE 379M, each System Element may be coded as a Fixed-length Pack, a Variable-length Pack or a Local Set according to SMPTE 336M. SMPTE 394M-2006 Page 3 of 7 p

19、ages VK LSystem Element3 System Item V K L System Element2 VK L System Element 1 Each System Element comprises one or more metadata values coded as a Local Set, Variable Length Pack or Fixed Length Pack Figure 2 Example of a GC System Item as a Sequence of Metadata Elements 5 GC System Scheme-1 Defi

20、nitions GC System Scheme 1 shall comprise the following System Element types as defined in Table 1. Table 1 Specification of the Elements in the GC System Scheme 1 Element Identifier Element Name Element Description 01h First Element A System Element coded as a local set that contains metadata perta

21、ining to the Content Package as a whole and is the first element in the System Item 02h Subsequent Element A System Element coded as a local set that contains metadata pertaining to the Content Package as a whole and is not the first element in the System Item 03h Picture Item Descriptor A System El

22、ement coded as a local set that contains metadata pertaining to any Picture Element in the Picture Item of the Content Package 04h Sound Item Descriptor A System Element coded as a local set that contains metadata pertaining to any Sound Element in the Sound Item of the Content Package 05h Data Item

23、 Descriptor A System Element coded as a local set that contains metadata pertaining to any Data Element in the Data Item of the Content Package 06h Control Data Set A System Element coded as a local set that contains control data pertaining to the Content Package 07h Compound Item Descriptor A set t

24、hat contains metadata pertaining to any essence element in the Compound Item of the Content Package 08h 0Fh Reserved Reserved 10h 7Fh Pack coded System Elements A System Element coded as a SMPTE 336M compliant pack SMPTE 394M-2006 Page 4 of 7 pages The Element Identifier value shall be used as the v

25、alue of byte 15 of the Set Key as defined in Table 2. Within any GC System Scheme 1 compliant System Item: The System Item shall start with a System Element of type “First Element”. There shall be exactly one instance of a System Element of type “First Element”. There may be zero or more instances o

26、f the other system elements as required. The total number of instances of System Elements shall not exceed the maximum defined in SMPTE 379M. Other System Elements not explicitly defined in Table 1 may be individually added by the creation of a separate document that normatively references this stan

27、dard. 5.1 Set Keys The Key of a System Element shall be as defined in Table 2. Table 2 Specifications of the Set Key for the System Elements Byte No. Description Value (hex) Meaning 112 As defined in SMPTE 379M, Table 1 See SMPTE 379M, Table 1 13 Item Type Identifier 14h GC-Compatible System Item 14

28、 System Scheme Identifier 02h GC System Scheme 1 15 Metadata or Control Element Identifier Table 1 As defined by Table 1 or by a separate document 16 Element Number xxh Unique Element Instance Number (Always 00h for the First Content Package Descriptor element) The KLV coded System Element of type “

29、First Element” shall have a KLV set key as defined in Table 2; it may have a KLV Length field with the value 0, and hence the KLV Value field may be absent. Each and every System Element of type “First Element” shall be of fixed length for a given Essence Container (of a given BodySID value). INFORM

30、ATIVE NOTE Since the System Item, where present, is the first Item in a Content Package, this allows decoders to identify an unambiguous starting point of the Content Package. Byte 16 shall be used to define the value of the Element Number in the range 00h7Fh. The System Element of type “First Eleme

31、nt” shall use the reserved value of “00h”. For all other instances of an element, the value shall be set by the encoder to be unique amongst all the elements in a System Item. This value shall be constant for a given System Element within an Essence Container. The use of this byte is only to identif

32、y System Elements between Content Packages within an Essence Container (of a given BodySID value). INFORMATIVE NOTE The unique element number allows multiple audio tracks to have several instances of a System Element containing metadata for each audio track, one for each sound track. Each instance o

33、f the Sound Item Descriptor will have a different Key for ease of identification and will include an Essence Track Number to link to the individual sound track that it describes. All System Elements which employ local set encoding shall be coded using 2-byte local tags and either 2-byte or 4-byte le

34、ngths. Byte 6 of the set Key shall have the respective values of 53h and 73h as defined by SMPTE 336M. The tag values used shall be defined by the appropriate System Element specification document. SMPTE 394M-2006 Page 5 of 7 pages The tag values have only the scope of the Content Package and shall

35、be neither entered nor looked up in the Header Metadata Primer Pack. The tag values shall be universally unique and either defined in SMPTE 405M or informatively copied into SMPTE 405M from the defining document. INFORMATIVE NOTE 2-byte lengths are typically used with frame-wrapping and 4-byte lengt

36、h with clip-wrapping. However, decoders must be prepared to decode whichever length is indicated in byte 6 of the Key. 5.2 Element Values A System Element of type “First Element” or “Subsequent Element” shall relate to the Content Package as a whole. Pack coded System Elements shall specify their sc

37、ope. All other GC System Scheme 1 Elements may optionally be linked to a specific Essence Element within the Content Package. The Essence Track Number within the System Element shall match the 32-bit value comprising bytes 13,14,15 and 16 of the linked Essence Element Key. This linking value, or bat

38、ch of linking values, shall be included in the appropriate System Element Value field to establish the link. If no linking values are present in the System Element then, by default, the System Element describes all essence elements of the associated type (e.g. Picture, Sound, Data, etc). NOTE This l

39、ink value is identical to the essence track number as defined in SMPTE 379M, but has only the scope of the essence in the Content Package within which it resides. It has no relationship to the Header Metadata Track Number property in SMPTE 377M. Most (but not all) of the individual items within the

40、System Element sets or pack may be characterized as follows: Those that define a single value which describes some aspect of the Essence Element in frame-wrapping mode or, Those that define a single value which describes some aspect of the content in clip-wrapping mode or, Those that define a multip

41、le value which describe some aspect of each frame of the content in clip-wrapping mode. These multiple values will typically be arrays so that the sequence of values in the array will relate to the sequence of frames in the clip. Those individual items that define multiple values for use in clip-wra

42、pping mode shall constrain the first value in the System Element to describe the first frame of the KLV wrapped Essence Element. Each subsequent value in the System Element shall relate to the next frame in the Essence Element. The number of values in the System Element will typically be equal to th

43、e number of frames in the Essence Element. The number of values in the System Element shall not exceed the number of frames in the Essence Element. However, the number of values in the System Element may be less than the number of frames in the Essence Element INFORMATIVE NOTE Individual data items

44、that may be used in this standard are defined or listed in SMPTE 405M. SMPTE 394M-2006 Page 6 of 7 pages Annex A (Informative) Use of System Item Metadata Within an MXF file, there are four potential locations for metadata (in order of preference): As part of the Header Metadata. As a separate data

45、stream component in an MXF file. Intimately associated with the essence via the System Item of a Content Package, as defined in this standard. Embedded within the essence stream itself. Common examples are VITC (Vertical Interval Time Code) and AES-3 channel status data. The order of priority of met

46、adata use is subject to many constraints, but the following text provides some guidance. As a rule, metadata is best placed in the Header Metadata wherever possible since that provides the greatest accessibility for all MXF readers. However, there are some limitations such as metadata size (limited

47、to 64 kB) and mapping constraints in live file creation. Bulky metadata, such as a stream of time-code, can be extracted from the Essence Container and placed in an MXF file as a data stream. This offers ease of access that is slightly less than that provided by the Header Metadata, but is more acce

48、ssible than parsing the contents of the Essence Container. Metadata that is created at the time of content creation may be presented as a live stream of audio-visual content. In this situation, metadata may be created at the same time as the audio-visual content, and, in this case, it is necessary t

49、o embed the metadata with the essence. This can be done by the traditional method of embedding in the essence stream itself, as with VITC, AES-3 Channel Status metadata and other, similar, examples, or by using the System Item. Both these methods of metadata carriage provide less access to the metadata than in a file environment. On the other hand, they are perfectly suited to live content creation that precedes the instantiation of a file. Thus, System Item metadata and control data is intended only for that which is intimat