1、 Copyright 2008 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved July 31, 2008 Table of Contents Page Foreword . 2 Intellectual Property 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 4 4 Glossary of Acronyms
2、, Terms and Data Types . 4 5 Introduction (Informative) 5 6 Generic Stream Partition Specification 6 6.1 Overview 6 6.2 Generic Stream Partition Pack. 6 6.3 Generic Stream Data Element Coding. 7 6.4 Use of KLV Fill . 10 6.5 Use of the RIP 10 6.6 Use of Stream ID 10 6.7 Byte Counting with Generic Str
3、eam Data 11 6.8 Blind Repartitioning of Generic Streams 11 7 Generic Stream Payload Mapping Specifications 11 7.1 Stream ID Linkage Mechanism 12 7.2 Indexing Generic Stream Data. 13 7.3 SMPTE Label for Essence Identification 13 7.4 SMPTE Label for Metadata Identification 14 8 Repetition . 15 8.1 Rep
4、etition Example (Informative) 15 Annex A Discussion of Stream Types (Informative) 18 Annex B Application of an MXF File (Informative) . 20 B.1 A Simple MXF File with a Non-Segmented Essence Container . 20 B.2 A Simple MXF File with a Segmented Essence Container . 20 B.3 A Multiplexed MXF File with S
5、egmented Essence Containers . 20 Annex C Bibliography (Informative) . 22 Page 1 of 22 pages SMPTE 410-2008 SMPTE STANDARD Material Exchange Format Generic Stream Partition SMPTE 410-2008 Page 2 of 22 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-
6、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, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technolo
7、gy 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 ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its
8、Administrative Practices. This SMPTE Engineering Document was prepared by Technology Committee W25. 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 possib
9、ility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. SMPTE 410-2008 Page 3 of 22 pages 1 Scope This document defines an extension of the MXF File Format that allows specific classes of
10、 data streams to be contained in MXF Body Partitions. The classes of data streams are either essence that is unevenly distributed along the timeline or large amounts of metadata that cannot suitably be stored in the Header Metadata. Examples for such data streams are time-varying metadata, structure
11、d text files and lumpy essence, i.e. that is not evenly spread along the timeline. The Generic Stream Container is not intended to carry metadata that could be placed in MXF Header Metadata or essence or metadata that could suitably be stored in the MXF Generic Container. This document defines the K
12、LV encoding methods used to carry the data stream. This document also defines partitions that are used to multiplex Generic Streams into the byte stream of MXF files. These Generic Stream Partitions provide for the carriage of Generic Streams in separate partitions from those partitions carrying Ess
13、ence Container data or Index Table segments. Essence and metadata payloads that are carried in Generic Stream Partitions are defined in associated documents. This document defines rules for the documents that specify the Generic Stream Payloads and their application. It also defines the basic linkin
14、g mechanisms of Generic Streams to the Header Metadata of the MXF file. 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
15、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 this document is, by default, normative, except: the Introduction, any section explicitly labeled
16、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 deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several poss
17、ibilities, 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) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“
18、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 in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the
19、 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 (“should“) as described. A conformant implementation need not implement optional provisions (
20、“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 authoritative definition. Tables shall be next, followed by formal languages, then figures, and
21、 then any other language forms. SMPTE 410-2008 Page 4 of 22 pages 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 editions indicated were valid. All standards are subject
22、to revision, and 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-2007, Data Encoding Protocol Using Key-Length-Value SMPTE 377M-2004, Television Material Exchange Format (MXF)
23、File Format Specification 4 Glossary of Acronyms, Terms and Data Types The general glossary of acronyms, terms and data types used in the MXF specification is given in SMPTE 377M. They are not repeated here to avoid any divergence of meaning. AU: Access Unit Access Unit: The smallest temporal sectio
24、n of a stream of data that is intended to be accessed independently. For video essence, an Access Unit is normally defined to be one complete picture (usually a frame, but occasionally a field). For audio essence, an Access Unit is normally defined to be either a fixed number of uncompressed samples
25、, or a single block of compressed data. (Note: This may also be called an Audio Frame.) Descriptive Metadata: Metadata strongly referenced, either directly or indirectly, from a DM Framework or a subset of a DM Framework. Generic Stream: A stream of data bytes with a defined format. Generic streams
26、are linear in nature, but may be divided into structured items or even temporally into Access Units Generic Stream Data: The data bytes within a generic stream partition. This includes all bytes from the start of the first key after the partition pack, excluding the filler immediately following the
27、partition pack if one exists, until the last byte before the start of the following partition pack key. Generic Stream Partition: The partition defined by this document, including all bytes from the start of the partition pack key to the byte before the start of the following partition pack key. Gen
28、eric Stream Payload: Those bytes of Generic Stream Data that constitute the Generic Stream. If the Generic Stream is Intrinsically KLV Wrapped (see Section 6.3.1), all keys and length fields as well as any KLV Fill items are regarded as part of the payload, otherwise these are excluded. Lumpy Essenc
29、e: Essence that is not continuous along a timeline. For example pre-rendered subtitles may be stored as still images that are associated with particular points along the timeline. Payload: Used to refer to the Generic Stream Payload. SID: Stream ID. TLV: Tag-Length-Value local set coding as used ins
30、ide SMPTE 336M KLV local sets. UL: SMPTE 298M Universal Label with a value given in the Registry defined by SMPTE 400M (RP 224) SMPTE 410-2008 Page 5 of 22 pages 5 Introduction (Informative) The MXF Format specification defines partitions that can contain Header Metadata repetitions, Essence Contain
31、er data, and Index Table segments either in separate partitions or within the same partition. However, there is no provision in SMPTE 377M for carrying large streams of data other than continuous essence that is regularly distributed along the timeline. This document defines the Generic Stream Parti
32、tion for carrying generic data streams within the MXF body. From the point of view of an MXF encoder or decoder, a Generic Stream may be regarded simply as an unstructured sequence of data bytes, or a sequence of multi-byte items. This document defines how this data is wrapped in KLV packets, how th
33、e Generic Stream Data is multiplexed into the MXF byte stream, and includes information that allows some manipulation of these streams independent of the semantics of the particular Generic Stream Payload. Further details of each Generic Stream are given by a mapping specification, described in Sect
34、ion 10, which defines the wrapping schemes to be used and the format of the payload data. For an MXF application that is programmed with knowledge of a particular Generic Stream payload mapping, the payload can be encoded, decoded and manipulated as required. In some MXF decoder applications, the pr
35、ecise nature of the stream data will be unknown or “dark”. It is important that these applications be able to extract the payload from a Generic Stream Partition and forward it to another application or codec device for processing. Similarly, it is important that an MXF encoder be able to receive a
36、Generic Stream Payload and write it to a valid Generic Stream Partition without detailed knowledge of its format; in practice all that is required are the correct values of the bits specified in Table 4 and Table 5. As much as possible, the applications interaction with the Generic Stream Data needs
37、 to be independent of the actual way in which any access units are divided and partitioned on the underlying KLV storage layer. In an MXF file, a Generic Stream is enclosed in KLV packets, and is then stored in the body of one or more Partitions. This document defines the following two component par
38、ts: 1. Generic Stream encapsulation 2. A Generic Stream Partition Pack which identifies the start of a Generic Stream Partition. The relationship between these components is illustrated in Figure 1. The linkage between the Header Metadata and the Generic Stream Data is provided by a StreamID and the
39、 precise details of this linkage mechanism is defined in the appropriate payload mapping specification. Header Metadata Next Partition Pack Generic Stream Partition Pack Partition Pack Stream linkage Stream encapsulationK LK L K L Figure 1 Relationship between Partition Components SMPTE 410-2008 Pag
40、e 6 of 22 pages 6 Generic Stream Partition Specification 6.1 Overview The Generic Stream Partition is defined in the following sections; an informative summary is shown below: 1. A Generic Stream Partition is a special kind of Body Partition. 2. A Generic Stream Partition includes one or more KLV-wr
41、apped Generic Data Elements. 3. A Generic Stream Partition contains data from a single Generic Stream. 4. A Generic Stream Partition does not include any essence container data, Header Metadata repetition or Index Table Segments. 5. The order of the Generic Stream Data Elements is significant and it
42、 is important that this is not altered by any application treating the Generic Stream Data Elements as dark. 6. The Generic Stream Data Elements may be placed in a single partition, or distributed over two or more partitions. 7. Each unique Generic Stream is assigned a Stream ID value that is unique
43、 within the file. Different Generic Streams can thus be uniquely identified even if there are several Generic Streams distributed throughout the file. 8. Generic Stream Partitions are included in the Random Index Pack. 6.2 Generic Stream Partition Pack The Generic Stream Partition Pack shall compris
44、e a Generic Stream Partition Pack Key, a Length and a Value as defined below. In accordance with SMPTE 377M, the Generic Stream Partition Pack shall be a KLV-coded, fixed-length pack as defined in SMPTE 336M. 6.2.1 Generic Stream Partition Pack Key The Key of the Generic Stream Partition Pack shall
45、be as defined in Table 1. Table 1 Partition Pack Key Value Byte No. Description Value (hex) Meaning 17 See SMPTE 377M, Table 1 As defined by MXF File Format Specification 8 Version Number 01h Registry Version at the point of registration of this Key 913 See SMPTE 377M, Table 1 As defined by MXF File
46、 Format Specification 14 Set / Pack Kind 03h Body Partition Pack 15 Partition Status 11h Generic Stream Partition 16 Reserved 00h Byte 14 of the SMPTE Key defines that the partition is a Body Partition. Byte 15 of the SMPTE Key defines that the partition is a Generic Stream Body Partition Note: The
47、Partition Pack keys defined in SMPTE 377M include flags for open or closed and complete or incomplete, which relate to the Header Metadata in that partition. These flags are not used for Generic Stream Partitions as according to Section 7.1.2 any metadata contained in a Generic Stream Payload is reg
48、arded as closed and complete. SMPTE 410-2008 Page 7 of 22 pages 6.2.2 Generic Stream Partition Pack Length In accordance with SMPTE 377M, it is preferred that the Length field of this KLV fixed length pack be BER long-form encoded using four bytes. MXF decoders shall be SMPTE 336M compliant and must
49、 respond to short or long-form BER encoding as received. Decoders shall not rely on a fixed number of bytes for length fields. 6.2.3 Generic Stream Partition Pack Value The value of the Generic Stream Partition Pack shall be as defined in SMPTE 377M, with the following settings: The value of the HeaderByteCount shall be set to zero indicating that there is no Header Metadata in this partition. The value of the IndexByteCount shall be set to zero indicating that there are no Index Table segments in this partition. The
