SMPTE RDD 9-2013 MXF Interoperability Specification of Sony MPEG Long GOP Products.pdf

1、 The attached document is a Registered Disclosure Document prepared by the proponent identified below. It has been examined by the appropriate SMPTE Technology Committee and is believed to contain adequate information to satisfy the objectives defined in the Scope, and to be technically consistent.

2、This document is NOT a Standard, Recommended Practice or Engineering Guideline, and does NOT imply a finding or representation of the Society. Errors in this document should be reported to the proponent identified below, with a copy to engsmpte.org. All other inquiries in respect of this document, i

3、ncluding inquiries as to intellectual property requirements that may be attached to use of the disclosed technology, should be addressed to the proponent identified below. Proponent contact information: Hiroshi Nakano Sony Corporation 4-14-1 Asahi-cho, Atsugi Kanagawa, 243-0014 Japan Email: Page 1

4、of 33 pages SMPTE RDD 9:2013 Revision of RDD 9-2009 Copyright 2013 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved February 6, 2013 SMPTE REGISTERED DISCLOSURE DOCUMENT MXF Interoperability Specification of Sony MPEG Long GOP

5、Products SMPTE RDD 9:2013 Page 2 of 33 pages Table of Contents Page 1 Scope 3 2 Reference Documents 3 3 Introduction . 3 4 Outline of MXF File Structure for this Mapping 4 5 MPEG Picture Data and AES3 Data Mapping . 5 5.1 Frame Wrappings . 5 5.2 System Item Mapping . 6 5.2.1 Overview of System Item

6、6 5.2.2 System Metadata Pack . 6 5.2.3 Package Metadata Set . 7 5.2.4 Picture Metadata Set 7 5.3 Picture Item Mapping 7 5.3.1 MPEG Picture Element Key 8 5.3.2 MPEG Picture Element Length . 8 5.3.3 MPEG Picture Element Value . 8 5.4 AES3 Sound Item Mapping 9 5.4.1 AES3 Sound Element Key 9 5.4.2 AES3

7、Sound Element Length . 10 5.4.3 AES3 Sound Element Value . 10 5.5 Data Item Mapping (Optional) 10 5.6 Temporal Reordering 10 6 SMPTE Labels for Essence Container Identification 11 7 SMPTE Labels for Essence Coding Identification 11 8 Application Issues . 12 8.1 Application of the KLV Fill Item . 12

8、8.2 Application of MXF Structure and Indexing Style . 12 8.2.1 Segmented Body Partition Style . 12 8.2.2 Single Body Partition Style . 14 8.3 Application of Index Table for Frame Wrapped MPEG Picture and AES Sound Essence 15 8.3.1 Essence Container and Index Table. 15 8.3.2 Index Table Items . 15 8.

9、3.3 Delta Entry Array . 16 8.3.4 Index Entry Array 18 8.3.5 Setting the Properties Specific for Long GOP MPEG. 20 8.4 Application of Random Index Pack. 22 Annex A UL Code List . 24 Annex B Constraints of the Conformant Implementation 26 B.1 Structure . 26 B.2 Header and Body Partition Pack Values 26

10、 B.3 Essence Descriptors . 26 B.4 Identification Set Value . 27 B.5 Timecode Representation in MXF Header and an Essence Container . 27 B.6 Index Table Segments 27 B.7 Random Index Pack . 28 B.8 Essence 28 B.8.1 System Item . 28 B.8.2 Picture Item 28 B.8.3 Sound Item . 28 B.8.4 Data Item 28 Annex C

11、Property Values of the Essence Descriptors 29 SMPTE RDD 9:2013 Page 3 of 33 pages 1 Scope This document specifies the mapping of MPEG-2 Picture (ES), AES3 audio and ANC packets into the MXF Generic Container. The MXF files created according to the details of this specification comply with the MXF sp

12、ecifications defined in the normative references, with a variation with respect to one new rule introduced in SMPTE ST 377-1. In conjunction with the referenced Standards, this RDD is intended to provide sufficient information to enable a developer to construct MXF files that will be compatible with

13、 Sony MPEG-2 Long GOP products. 2 Reference Documents Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 326:2000) although, during a transitional phase, the document as published (printed or PDF) may bear an older designation (such as SMPTE

14、 326-2000). Documents with the same root number (e.g. 326) and publication year (e.g. 2000) are functionally identical. SMPTE ST 326:2000, Television SDTI Content Package Format (SDTI-CP) SMPTE ST 331:2011, Element and Metadata Definitions for the SDTI-CP SMPTE ST 377-1:2011, Material Exchange Forma

15、t (MXF) File Format Specification Amendment 2:2012 to SMPTE ST 377-1:2011 SMPTE ST 378:2004, Television Material Exchange Format (MXF) Operational Pattern 1a (Single Item, Single Package) SMPTE ST 379-1:2009, Material Exchange Format (MXF) MXF Generic Container SMPTE ST 381-1:2005, Television Materi

16、al Exchange Format (MXF) Mapping MPEG Streams into the MXF Generic Container SMPTE ST 382:2007, Material Exchange Format Mapping AES3 and Broadcast Wave Audio into the MXF Generic Container SMPTE ST 385:2012, Material Exchange Format (MXF) Mapping SDTI-CP Essence and Metadata into the MXF Generic Co

17、ntainer SMPTE ST 400:2012, Television SMPTE Labels Structure SMPTE ST 436:2006, Television MXF Mappings for VBI Lines and Ancillary Data Packets SMPTE RP 210, Metadata Element Descriptions SMPTE RP 224, SMPTE Labels Register SMPTE RDD 18:2012, Acquisition Metadata Sets for Video Camera Parameters Re

18、commendation ITU-R BT.709-5 (04/02), Parameter Values for the HDTV Standards for Production and International Programme Exchange 3 Introduction The MXF Generic Container is a streamable Essence Container that can be placed on any suitable transport and stored. SMPTE ST 379-1 defines the MXF Generic

19、Container as the native Essence Container in MXF SMPTE RDD 9:2013 Page 4 of 33 pages files. SMPTE ST 381-1 defines how MPEG streams, as identified by an ISO 13818-1 stream_id value, can be mapped in the MXF Constrained Generic Container. SMPTE ST 382 defines how AES3 and Broadcast Wave Audio can be

20、mapped in the MXF Generic Container. SMPTE ST 385 defines the System Item that is compatible with SMPTE ST 326 (SDTI-CP) and also defines how SDTI-CP essence and metadata can be used in the MXF Generic Container. This document specifies the mapping of MPEG Picture (ES) compatible with MPEG stream an

21、d AES3 audio into the MXF Generic Container. This document also specifies the MXF file format which includes unique identifiers, Operation Pattern, Partitions, Index Table Segments and RIP. The common basic structure is described in this document 4 Outline of MXF File Structure for this Mapping Figu

22、re 1 shows the outline of the MXF file structure. The file consists of a Header Partition, segmented Body partition(s), a Footer Partition and a Random Index pack. Picture, Sound and System Items are mapped into the Essence Container and placed in each Body Partitions. The Data Item is optional. Bec

23、ause of the MPEG Long GOP structure of Picture Item, segmented Index Table is used together with Random Index pack. More detailed explanation can be found in Section 8 (Application Issues). Figure 1 Outline of MXF File HPP: Header Partition Pack BPP: Body Partition Pack FPP: Footer Partition Pack Fi

24、ll2: The length of the KLV Fill Item should be required to align to a KAG boundary. Some of the aspects of this structure are shown below. It is only necessary to include one Index Table Segment for each Body Partition period on the sender side. It is easy to perform the function “Play while receivi

25、ng file” on the receiver side. It is easy to pick extract a “Partial file”. A list of major constraints for this file structure is given in Table 1. Detailed constraints are listed in Annex B. Note: In Figure 1, the order of Items in the Content Package is System, Picture, Sound and Data Items, as d

26、escribed in other documents (e.g. SMPTE ST 379-1, SMPTE ST 386, SMPTE ST 387, and so on), while SMPTE ST 436 defines Data Item precedes Picture and Sound Items. This Element ordering issue is being discussed in the ST 436:2006 revision group and it is expected to be resolved in its revision. BPPEdit

27、UnitHPPHeaderMetadataFPPRandomIndexPackFile HeaderFile BodyFile FooterEditUnitEditUnitBPPIndexTableEditUnitIndexTableBPPEditUnitEditUnitEditUnitIndexTable EditUnitEditUnitMPEGSystem AESFillK L K L K L FillK L K L FillK L AESK L FillK L AESK L FillK L AESK L FillK L DataK L FillK L(optional)SMPTE RDD

28、 9:2013 Page 5 of 33 pages Table 1 Constraints for RDD 9 Stream Products Item Constraints Operational Pattern 1a - Origin and Duration1Wrapping (Interleaving) are used to express GOP Pre-Charge and Roll-Out. Frame by Frame (coded order) KAG2512 size System Item Compliant to ST 326 and ST 385, includ

29、es the Frame by Frame Timecode and UMID Video packetization Compliant to ST 381-1, MPEG-2 ES GOP structure Max 15 frames/GOP (N=15, M=3, open GOP / closed GOP) / 1920x1080i Max 12 frames/GOP (N=12, M=3, open GOP / closed GOP) / 1280x720p Variable length GOPs are permitted. Audio sampling 48 kHz lock

30、ed Audio packetization Compliant to ST 382, AES3, 1ch/Element (min 2 to max 8 channels ) Data Item (optional) Compliant to ST 436, Optionally used for Ancillary packet Timecode System Item and Header Metadata 5 MPEG Picture Data and AES3 Data Mapping The mapping of MPEG Picture (ES) data is as defin

31、ed in SMPTE ST 381-1. The mapping of AES3 digital audio data is defined by SMPTE ST 382. This specification uses Frame Wrapping as defined by SMPTE ST 379-1. The System Item is defined by SMPTE ST 326, and mapped into the MXF by SMPTE ST 385. The order of Items in each Edit Unit is System, Picture,

32、Sound and Data (where the Data Item is optional). 5.1 Frame Wrappings This document requires the use of Frame Wrapping as defined by SMPTE ST 379-1, Section 5.4.1. In the case of audio locked to video at 25 (or 50) content packages per second, each Element will contain the same number of samples, fo

33、r example 1920 (or 960). In the case of audio locked to video at 30*1000/1001 content packages per second, the number of samples in each Element will vary to maintain a correct aggregate rate. Typically the number of samples varies according to a 5-frame sequence, 1602, 1601, 1602, 1601, and 1602. I

34、n the case of audio locked to video at 60*1000/1001 content packages per second, the number of samples in each Element will vary to maintain a correct aggregate rate. Typically the number of samples varies according to a 5-frame sequence, 801, 801, 800, 801, and 801. The number of samples in each co

35、ntent package is calculated from the Length field of the surrounding KLV packet, divided by the value of the BlockAlign Property of the AES3 Audio Essence Descriptor. In the case of audio locked to video at 24*1000/1001 content packages per second, each Element will contain the same number of sample

36、s, for example 2002. An arrangement of System, Picture, and Sound Items in a Frame Wrapping is shown in Figure 2. It shows the case of 4 channels AES3 audio. 1In legacy RDD 9 files (version 1.2), the duration of the top level file package does not contain the Pre-Charge or Roll-Out as defined in SMP

37、TE ST 378. In RDD 9 files (version 1.3), the duration of the top level file package contains the Pre-Charge but doesnt contain Roll-Out as defined in SMPTE ST 377-1. 2Refer to Section 8.1 Application of the KLV Fill Item. SMPTE RDD 9:2013 Page 6 of 33 pages Figure 2 Frame Wrapping of System, Picture

38、 and Sound Elements 5.2 System Item Mapping The System Item in each Edit Unit consists of System Metadata Pack, a Package Metadata set and Picture Metadata Set. 5.2.1 Overview of System Item System Item is placed at the beginning of every Edit Unit and contains information on the essence item and th

39、e metadata attached to the frames, and it shall comply with SMPTE ST 385 (Mapping SDTI-CP Essence and Metadata into the MXF Generic Container). Typical System Item consists of the following four Elements and its size is the same as one KAG size (200h). System Metadata Pack contains Package Rate, Mul

40、tiple EC UL, LTC Package Metadata Set contains UMID, Essence Mark (optional) Picture Metadata Set contains Acquisition Metadata Sets (optional) Fill Item Figure 3 shows the outline of System Item. Figure 3 Typical System Item structure 5.2.2 System Metadata Pack The Pack Key is 06.0E.2B.34.02.05.01.

41、01.0D.01.03.01.04.01.01.00 as defined in Table 1 of SMPTE ST 385. Length of this pack shall be fixed, i.e. 57-byte payload. Also, each Property shall be described in the provided field without tag and length. The sequence and values shall comply with SMPTE ST 326. System Metadata Bitmap (“SMB“ in th

42、e figure) indicates the presence of metadata in the Pack, and of essence data within the Edit Unit, should be set to 0101_1100b, when Data Item is not recorded or 0101_1110bwhen Data Item is recorded. CPTGCEClabelSMBCPRSystemMetadataPackKeyLCCCHT LLVLKTSystem Metadata Pack Package Metadata Set1 1 1

43、2 2 16 16 1616 4 16 4 21 64 21KLV meta(EssenceMark)252maxBodyUMIDLPictureMetadataSetKeyL16 4T LLensUnitMetadata29max21Picture Metadata SetFillFillItemKeyL16 4VLKT LCameraUnitMetadata100max21VLKPack Length (= 39h) Set Length Set Lengthone KAG size (= 200h)1 1PackageCreationDateUserDate(LTC)V VTTPacka

44、geMetadataSetKeySMPTE RDD 9:2013 Page 7 of 33 pages The value of Continuity Count (“CC“ in the figure) shall be monotonically increasing within a file. It does not have to start from 0, and is back to 0000hfollowing full count FFFFh. SMPTE Universal Label (“GC EC label“ in the figure) shall be set t

45、o a suited MXF Generic Container label which is the same with the Essence Container Property of Multiple Descriptor Set. Package Creation Date should be blank. Tag (“T“ in the figure) and the remains are filled with 00h. LTC shall be described in the User Date column. Since it complies with SMPTE ST

46、 331, it starts with CP-Tag 81hand digits of Frame, Second, Minute, and Hour are placed with flags such as DF, and then Binary Group data (4 bytes) is placed, and remaining 8 bytes are filled with 0. 5.2.3 Package Metadata Set The Set Key is 06.0E.2B.34.02.43.01.01.0D.01.03.01.04.01.02.nn as defined

47、 in Table 2 of SMPTE ST 385. The parameter nn indicates the number of Metadata Blocks within the Package Metadata Set, and the value is set to 2 when there are UMID and KLV Metadata, 1 when there is just UMID, and 0 when there is no UMID nor KLV Metadata. Each metadata block is described with 1-byte

48、 CP-Tag and 2-byte Length field. Typical kind of metadata in this specification, shown in Figure 3, is defined as follows: Frame-by frame UMID should be described as the first block. Extended UMID (64 bytes) should be described with CP-Tag 83h. When omitting the block, Tag and later are not describe

49、d. Decoders should support the cases where only Basic UMID is described or the item is blank. EssenceMarkTMis normally described as KLV Metadata as the second block. Value is less than 32 bytes, recorded with CP-Tag 88h. When omitting the item, Tag and later are not described. Other kind of KLV Metadata may be present with CP-Tag 88hinstead of EssenceMarkTM. If there are no items in Package Metadat