SMPTE ST 2067-5-2013 Interoperable Master Format - Essence Component.pdf

《SMPTE ST 2067-5-2013 Interoperable Master Format - Essence Component.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 2067-5-2013 Interoperable Master Format - Essence Component.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

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

2、verview 4 4.1 File Format Requirements (Informative) . 4 4.2 General IMF Essence Component and Shims 4 5 Essence Component File Parameters and Constraints . 5 5.1 Essence Track Parameters and Constraints . 5 5.2 Header Metadata and Operational Pattern Constraints . 9 5.3 Header Metadata Parameters a

3、nd Constraints . 10 5.4 Descriptive Metadata Parameters and Constraints . 12 6 Generic Shim . 12 6.1 Shim Identifier 12 6.2 Shim . 12 6.3 General Essence 13 6.4 Picture Components . 13 6.5 Audio Components . 13 6.6 Data Components 14 6.7 Header Metadata . 14 Page 1 of 14 pages SMPTE ST 2067-5:2013 S

4、MPTE STANDARD Interoperable Master Format Essence Component SMPTE ST 2067-5:2013 Page 2 of 14 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of Ameri

5、ca, 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. Participation in these Committees is open to all with a bona fide interest in their work.

6、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 Practices. SMPTE ST 2067-5 was prepared by Technology Committee 35PM. Intellectual Propert

7、y 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 document may be the subject of patent rights. SMPTE shall not be held responsibl

8、e for identifying any or all such patent rights. Introduction This section is entirely informative and does not form an integral part of this Engineering Document. The Interoperable Master Format (IMF) is a file-based framework designed to represent one or more high-quality versions of the same fini

9、shed work destined for distribution channels worldwide. IMF architecture separates composition metadata and essence into separate file objects to promote re-use end efficient operation. In IMF, essence data (and associated, essence-specific metadata) is stored within MXF Generic Containers contained

10、 in MXF files. This document provides a common set of characteristics (a common formulation) for these MXF files, termed Essence Components. SMPTE ST 2067-5:2013 Page 3 of 14 pages 1 Scope This standard defines the IMF Essence Component, an OP1a MXF structure for interchange of audio, picture and da

11、ta essence. It defines data structures for interchange at the signal interfaces of networks or storage media, but does not define internal storage formats for compliant devices or mappings for particular essence encodings. It also defines metadata expressions used to communicate allowable variations

12、 in the formulation of an IMF Essence Component. 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, bu

13、t 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 as “Informative“ or ind

14、ividual 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 possibilities, one is recom

15、mended 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“ and “need not“ indicate

16、 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 provision will never b

17、e 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 (“may“) and need not imp

18、lement 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 then any other langua

19、ge forms. 3 Normative References Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 278:2004) although, during a transitional phase, the document as published (printed or PDF) may bear an older designation (such as SMPTE 278M-2004). Document

20、s with the same root number (e.g. 278) and publication year (e.g. 2004) are functionally identical. The following standards contain provisions that, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All

21、standards are subject 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 330:2011, Unique Material Identifier (UMID) SMPTE ST 2067-5:2013 Page 4 of 14 p

22、ages SMPTE ST 377-1:2011, Material Exchange Format (MXF) File Format Specification 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 379-2:2010, Material

23、 Exchange Format (MXF) MXF Constrained Generic Container SMPTE ST 380:2004, Television Material Exchange Format (MXF) Descriptive Metadata Scheme-1 SMPTE ST 410:2008, Material Exchange Format Generic Stream Partition SMPTE ST 436:2006, Television MXF Mappings for VBI Lines and Ancillary Data Packets

24、 4 Overview The design of IMF Essence Component recognizes that some flexibility is required in the formulation of the MXF to accommodate a range of use cases to which IMF architecture may be applicable. To limit the variety of formulation a decoder must support (and to simplify the description of t

25、hese variations), this specification includes a shim concept that describes the variant aspects of IMF Essence Component using keyword parameters (with constrained values) that can be used to describe a specific formulation. This has the goal that engineers can develop IMF Applications, using IMF Es

26、sence Component as a core component, knowing that allowable variations can be defined by the Application. This allows IMF applications to satisfy their respective requirements (by taking advantage of IMF Essence Components flexibility) while reusing the same core specification and retaining interope

27、rability. 4.1 File Format Requirements (Informative) IMF Essence Component addresses the problem of having a common essence file format in an architecture that is expected to accommodate many essence encodings. In an ideal world, a single essence representation would be standardized on. Unfortunatel

28、y, over time, requirements for a facility change. The facility that started as SD introduces HD. The compression format of today gets replaced with a better one from tomorrow. Stereo audio gets upgraded to multi-channel and multi-lingual. In parallel, a facility operates with a constant pressure to

29、reduce the cost of production, distribution and publishing. In order to build systems that work at the MXF level rather than, e.g., at the MPEG or JPEG2000 level, IMF Essence Component provides a set of rules that MXF encoders and MXF decoders must follow. This brings many advantages. It allows a de

30、vice to query the picture size without having to implement a decoder for each essence type you simply read the MXF metadata. It allows a business process to be specified with an action such as: If (16:9), then transcode (center-cut-out) This action can be specified without the executor of process, h

31、uman or system, needing to know the details of underlying codec type that is something for the transcoder or reproducer to address. In general, this allows business systems to deliver work order requests to content-manipulation devices, which are in turn configured to support delivery specifications

32、. 4.2 General IMF Essence Component and Shims To maximize commonality across applications, this specification is divided into general provisions that apply to all applications, and specific constraint sets, called shims, that apply to defined applications. SMPTE ST 2067-5:2013 Page 5 of 14 pages The

33、 general provisions shall apply to all IMF Essence Components, and thus represent the maximum required capability of ingest servers, catch servers, playout servers, transcoders and other IMF compatible devices. Within these general provisions however are many potential variants - a shim may be used

34、to identify a particular variant. A shim is not intended to be a runtime element of a system that processes files as defined by this standard. Rather, it is provided as a defined means of expressing constrained variants of this standard by application designers. Each shim shall provide a further set

35、 of constraints that reduce the range of variability that may be needed in well-defined categories of applications. For example, these categories may address particular type of programming or programming genres, or they may address requirements of particular broadcast station groups. Documents that

36、reference this standard may extend the shim to address domain-specific variants, but shims shall not be used to add new required capability to the general provisions. They shall be limitations on the general provisions. Thus, the general provisions may be non-restrictive in some areas and this is in

37、tentional. In any given facility design or interchange specification based on IMF Essence Component, there may be one or more tightly defined shims. Typical examples are to have a shim for SD content, a shim for HD content and a shim for web content. Each of these shims tightly defines the codecs an

38、d layout for the particular business application. In this specification, shim parameters will be highlighted as follows: Shim parameter Definition example Semantic definition of the example shim parameter 5 Essence Component File Parameters and Constraints 5.1 Essence Track Parameters and Constraint

39、s 5.1.1 General IMF Essence Components shall each contain a single MXF essence Track of a single essence type. They shall be subject to the general constraints listed below. 1. Essence in an IMF Essence Component shall be wrapped using the MXF Generic Container (GC), either SMPTE ST 379-1 or SMPTE S

40、T 379-2. 2. An IMF Essence Component shall be a mono-essence MXF file. 3. An IMF Essence Component shall be frame wrapped for picture essence, per the designated GC. 4. An IMF Essence Component shall be clip wrapped for audio essence, per the designated GC. 5. An IMF Essence Component shall be clip

41、wrapped or frame wrapped for data essence, per the designated GC. 6. An IMF Essence Component shall be regularly partitioned when frame wrapped. 7. Each body partition in an IMF Essence Component shall exclusively have metadata, index tables, or essence. 8. An IMF Essence Component shall be signaled

42、 as closed and complete in the header or footer partition. 9. An IMF Essence Component shall have distributed and complete index tables. 10. An IMF Essence Component shall be signaled as OP1a, per SMPTE ST 378. 11. An IMF Essence Component should not have a system item. SMPTE ST 2067-5:2013 Page 6 o

43、f 14 pages 12. An IMF Essence Component shall have a KAG size of 1. 13. An IMF Essence Component shall have its primary package identifier set to the identity of the top-level file package within the essence component file. The UMID, per SMPTE ST 330, of the top-level file package in the essence com

44、ponent file shall be the unique identifier of the essence component. 14. On creation, a minimum 8kByte fill shall follow the header partition to allow for in-place extension. 15. All data sets shall follow MXF generation ID rules. 16. An IMF Essence Component may contain DMS-1 (SMPTE ST 380) metadat

45、a schemes. 17. An IMF Essence Component may contain private metadata schemes. These parameters are described in the sections below. Parameters may be further constrained by shims as described in the annexes or external documents. 5.1.2 Generic Container IMF Essence Component files shall use the MXF

46、Generic Container to wrap essence. Either the older unconstrained “MXF Generic Container” (SMPTE ST 379-1) or the newer “MXF Constrained Generic Container” (SMPTE ST 379-2) may be used. The selected GC specification shall exclusively define the use of the GC for a given application; the GC specifica

47、tion not selected shall be ignored in that same application. Note: SMPTE ST 379-2 is recommended in the case where there is no need for compatibility with SMPTE ST 379-1. Shim parameter Definition gc_type Default value: none Type: enumeration Values: “379-1-gc”, “379-2-constrained-gc” 5.1.3 Mono Ess

48、ence Only one essence track shall exist in the file package. Only one type of essence element shall be present (i.e. data, audio, picture or compound) in the essence container. Audio files containing interleaved channels shall be considered as mono-essence regardless of the number of channels and sh

49、all be described by a single track in the file package. The mono-essence flag in the OP1a header metadata field shall be set. 5.1.4 Interleaving IMF Essence Components shall not contain interleaved Generic Containers. 5.1.5 Partitions A partition in an IMF Essence Component shall only have one of the following types of data in it: Header metadata; Essence; Index table; SMPTE ST 410 generic stream. SMPTE ST 2067-5:2013 Page 7 of 14 pages Shim parameter Definition partition_spacing Default value: 60 seconds Type: floating point