1、 Copyright 2012 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved April 24, 2012 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3 4 Defi
2、nition of Acronyms, Terms and Data Types 4 5 Partition Multiplex . 4 5.1 Partition Duration . 5 6 Header Metadata . 6 7 Operational Pattern 6 8 Generic Container 7 Page 1 of 7 pages SMPTE ST 2049:2012 SMPTE STANDARD Low Latency Streaming MXF OP 1a SMPTE ST 2049:2012 Page 2 of 7 pages Foreword SMPTE
3、(the Society of Motion Picture and Television Engineers) is an internationally-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, Re
4、commended Practices, and Engineering Guidelines, are prepared by SMPTEs Technology 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 Engineeri
5、ng Documents are drafted in accordance with the rules given in Part XIII of its Operations Manual. SMPTE ST 2049 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
6、this standard. However, attention is drawn to the possibility 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. Introduction This section is entirely informative and does not form an inte
7、gral part of this Engineering Document. This standard defines a proper subset of MXF using Op1a for an application where a camera or an audio/video signal source is converted to an MXF file, transported on a data network and converted back an audio/video signal in the shortest practical time; i.e. w
8、ith the lowest latency. The standard does not prohibit the sending or receiving device from storing the MXF file so a broader range of applications can be addressed. It also includes design features that allow a receiver to “join” the MXF stream in progress and start playout in a limited number of f
9、rame times. The exact number of frame times depends on the architecture of the sender the MXF receiver as well as the underlying MXF stream or file format. This standards design goals were established for low latency applications like camera to IP network to playout for live events or audio/video st
10、ream transfers. Sample use cases that could use this standard include the streaming of an existing MXF file over a network and the recording this stream as an MXF file at the receiver. Other use cases include systems that convert live signals into a MXF on-the-fly, streaming the file over a network
11、and playing-back as real-time signals or recording as MXF files at the receiver. SMPTE ST 2049:2012 Page 3 of 7 pages 1 Scope This standard defines a sub-set of the Material Exchange Format (MXF) for low latency streaming applications that use Operating Pattern 1A. Latency is defined as the delay ti
12、me between image/sound acquisition and the image/sound display. The design is intended to support both CBR and VBR essence types. In this document, the terms “MXF file” and “MXF stream” are used in an interchangeable manner. For easier reading only the term “MXF file” is being used exclusively throu
13、ghout the following sections. 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
14、, 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 as “Informative“ or individual paragraphs
15、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 possibilities, one is recommended as particula
16、rly 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“ and “need not“ indicate courses of action
17、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 provision will never be defined in the fu
18、ture. 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 (“may“) and need not implement them as desc
19、ribed. 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 then any other language forms. 3 Normati
20、ve References Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 378:2004) although, during a transitional phase, the document as published (printed or PDF) may bear an older designation (such as SMPTE 378M-2004). Documents with the same roo
21、t number (e.g. 378) and publication year (e.g. 2004) are functionally identical. The following standards contain provisions which, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subj
22、ect to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE ST 2049:2012 Page 4 of 7 pages SMPTE ST 377-1:2011, Material Exchange Format (MXF) File Format Speci
23、fication Amendment 1:2012 to SMPTE ST 377-1:2011 SMPTE ST 378:2004, Material Exchange Format (MXF) Operational Pattern 1A (Single Item, Single Package) SMPTE ST 379-2:2010, Material Exchange Format (MXF) MXF Refined Generic Container 4 Definition of Acronyms, Terms and Data Types 4.1 Latency time di
24、fference between the image/sound capture at an MXF sender and the MXF receivers image/sound display; this includes codec, network and other latencies of the system. 4.2 Partition Duration the duration of Essence in one partition. 5 Partition Multiplex The following constraints are defined regarding
25、the partition multiplex of the MXF file: The MXF file shall not contain a Run-In. The MXF file shall contain one Header Partition and this Header Partition shall not contain any Essence and shall not contain any Index Table segments. The MXF file shall contain zero or more Body Partitions. All Body
26、Partitions shall contain either Header Metadata or Essence Container data or one Index Table segment. If a Body Partition contains Essence Container data, the duration of this Partition shall follow the definitions given in Section 5.1. If the Body Partition contains an Index Table segment, this Ind
27、ex Table segment shall index the Essence Container data of the previous Partition containing essence. The order of Body Partitions shall be as follows: 1. The 1stBody Partition shall contain Essence Container data only. Note: If the Essence Container duration exceeds the maximum duration of essence
28、of one partition, more Body Partitions are needed. In this case the total count of Body Partitions is at least 4. 2. The 2ndBody Partition shall contain one Index Table segment only. 3. The 3rdBody Partition shall contain Header Metadata only. 4. All following Body Partitions shall follow the patter
29、n of numbers 1,2 and 3. This order shall not change. The last Body Partition shall only contain one Index Table segment. SMPTE ST 2049:2012 Page 5 of 7 pages The MXF file shall contain one Footer Partition. The Footer Partition shall contain Header Metadata and may contain one or more Index Table Se
30、gments. This Index Table segment shall index the complete Essence Container. The MXF file may contain a Random Index Pack. 5.1 Partition Duration If a Body Partition contains Essence Container data, the duration of this Partition shall be one of the values defined in Table 1. Essence containers may
31、be field-wrapped or frame-wrapped (see Section 8).For field-wrapped essence, all body partitions with essence shall contain an even number of content packages, including the last body partition with essence. Compliance with the partition duration values in Table 1 shall consider the product of the e
32、dit rate and partition duration. This product yields the number of content packages per partition. The number of content packages shall be calculated as follows: Content packages per partition: Ceiling (EditRate) * Partition Duration Where Ceiling(x) shall be defined as follows: For field-wrapped es
33、sence: The smallest integer not less than x, which gives an integer number of frames. For frame-wrapped essence: The smallest integer not less than x. All Body Partitions which contain essence, except the last one, shall contain the calculated number of content packages. The last partition may conta
34、in fewer content packages, but shall not contain more. Table 1 Operating points of Partition durations Operating Point ID Partition Duration 1 1 second 10 10 seconds 20 20 seconds 30 30 seconds 60 60 seconds Notes (Informative): The provisions for partition duration and the exact number of Content P
35、ackages (CPs) described above are intended to simplify the receivers design and avoid problems with an odd number of field-wrapped CPs. Provisions in SMPTE ST 379-2 and SMPTE ST 377-1:2011 constrain the duration of each CP. Specifically, SMPTE ST 379-2, Section 8.4.1, Frame Wrapping, states that the
36、 duration of every CP is constant and matches the Edit Unit duration in the related File Package tracks. Since this standard allows only field-wrapping or frame-wrapping, the terms Content Package and Edit Unit are equivalent. SMPTE ST 2049:2012 Page 6 of 7 pages If interlaced material is frame-wrap
37、ped, then every CP will contain two fields, because the duration of every CP is constant. Using long GOP compression systems with this standard is allowed, but it is not encouraged. If long GOP compression is used with this standard, the body partitions will usually not start at the start of the GOP
38、 in the compressed video stream, hence, the I-frames fall where they may. Content Packages that are used for pre-charge or roll-out shall be counted to the sum of Contest Packages per Partition as any other Content Package. 6 Header Metadata Each Body Partition which contains Header Metadata (see Se
39、ction 5) and the Footer Partition shall include the same or an updated instance of the Header Metadata of the Header Partition and previous Body Partitions. The Header Partition and all Body Partitions shall be incomplete. The Footer Partition shall be closed and complete. Note: The Header Partition
40、 and Body Partitions can be open or closed. Note: When the duration of the stream is not known (e.g. in a Live use case) all values of Duration properties are to be set to -1. In cases where the duration of the stream is known (e.g. when a complete file will be streamed) the Duration properties are
41、to be set to the correct value. Descriptive Metadata may be present in Partitions that contain Header Metadata. In each Partition the maximum size of HeaderByteCount shall not exceed 64 kB. 7 Operational Pattern The MXF file shall use Operational Pattern OP1a. At all occurrences the Operational Patt
42、ern Universal Label shall be set to the following rules: Table 2 Universal Label byte range for the Operational Pattern Byte No. Description Value Meaning 1-12 Defined in SMPTE ST 377-1 See SMPTE ST 377-1 13 Operational Pattern: Item Complexity See SMPTE ST 378 Item Complexity 14 Operational Pattern
43、: Package Complexity See SMPTE ST 378 Package Complexity 15 Operational Pattern Definition See Table 3 Qualifier bits (see Table 3) 16 Operational Pattern Definition See SMPTE ST 378 SMPTE ST 2049:2012 Page 7 of 7 pages Table 3 Byte 15 values of the Operational Pattern UL Bit number Values and descr
44、iption 0 See SMPTE ST 377-1 1 Shall be set to 0 (internal Essence) 2 Shall be set to 0 (stream file) 3 See SMPTE ST 377-1 4-7 See SMPTE ST 377-1 Decoders shall ignore MXF files containing any other value of the Operational Pattern label. 8 Generic Container The MXF file shall use internal essence only. The essence shall be frame-wrapped or field-wrapped defined by SMPTE ST 379-2. The KAG shall be 1.
