1、 Approved Approved Copyright 2014 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved September 16, 2014 SMPTE RP 2089:2014 SMPTE RECOMMENDED PRACTICE Carriage of EIDR Identifiers in MXF Files Page 1 of 6 pages Table of Contents F
2、oreword . 2 Intellectual Property 2 Introduction . 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3 4 EIDR DM Scheme . 4 4.1 General 4 4.2 EIDR DM Scheme Label . 4 4.3 EIDR Framework Set . 4 5 Basic Application . 5 SMPTE RP 2089:2014 Page 2 of 6 pages Foreword SMPTE (the Society o
3、f 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, Recommended Prac
4、tices, 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 Engineering Documents a
5、re drafted in accordance with the rules given in its Standards Operations Manual. SMPTE RP 2089 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 this Engineering
6、Document. 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 integral
7、part of this Engineering Document. The Entertainment ID Registry (EIDR) Identifier (as specified in SMPTE RP 2079) is used for global unique identification of movie and TV content. It is desirable to associate EIDR Identifiers with essence across applications of the MXF file format, without modifica
8、tions to these applications, and both at and after initial file creation. This can be achieved using the Descriptive Metadata Scheme plug-in mechanism specified in SMPTE ST 377-1. A Basic Application, specified in Section 5, is used when a single EIDR Identifier is associated with an output timeline
9、 of an MXF file. More complex applications, specified elsewhere, can associate multiple EIDR Identifiers with a file. For instance, a distinct EIDR DM Framework Set, and hence EIDR Identifier, can be associated with individual File Packages if the MXF file is a composite of multiple individual progr
10、ams. SMPTE RP 2089:2014 Page 3 of 6 pages 1 Scope This Recommended Practice specifies a Descriptive Metadata Scheme (as specified in SMPTE ST 377-1 and SMPTE ST 377) that allows an EIDR Identifier (as specified in SMPTE RP 2079) to be associated with essence contained in an MXF file. It also specifi
11、es a set of constraints to be used when a single EIDR Identifier is associated with an entire 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 t
12、ext is text that is potentially 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,
13、 any section explicitly labeled 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“ i
14、ndicate that, among several possibilities, 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
15、 prohibited. The keywords “may“ 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” an
16、d in addition indicates that the 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
17、 implement optional provisions (“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 fo
18、rmal languages; then figures; and then any other language forms. 3 Normative References 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 a
19、re 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 377-1:2009, Material Exchange Format (MXF) File Format Specification SMPTE ST 377:2004, Ma
20、terial Exchange Format (MXF) File Format Specification SMPTE RP 2079:2013, Digital Object Identifier (DOI) Name and Entertainment ID Registry (EIDR) Identifier Representations SMPTE RP 2089:2014 Page 4 of 6 pages 4 EIDR DM Scheme 4.1 General The EIDR DM Scheme may be used in any MXF file as long as
21、Descriptive Metadata Plug-ins are supported, including MXF Files conforming to earlier revisions of SMPTE ST 377-1 such as SMPTE ST 377:2004. 4.2 EIDR DM Scheme Label If one or more EIDR DM Framework Sets are present in an MXF file, the DM Schemes item of the Preface Set shall include exactly one in
22、stance of the UL defined in Table 1. Table 1 EIDR DM Scheme Label Byte No. Description Value (hex) Meaning 17 See Table 21 of SMPTE ST 377-1 Generic Universal Label for MXF Descriptive Metadata Schemes 8 Version Number 0Dh Registry Version in which the specific key first appeared 912 See Table 21 of
23、 SMPTE ST 377-1 Generic Universal Label for MXF Descriptive Metadata Schemes 13 Structure / Scheme Kind 05h EIDR Descriptive Metadata Scheme 14 Version 01h EIDR Descriptive Metadata Scheme Version 1 15 Reserved 00h 16 Reserved 00h 4.3 EIDR Framework Set 4.3.1 Key The Set Key of the EIDR DM Framework
24、 Set shall be as specified in Table 2. SMPTE RP 2089:2014 Page 5 of 6 pages Table 2 EIDR DM Framework Set Key Byte No. Description Value (hex) Meaning 17 See Table 22 of SMPTE ST 377-1 Generic Key for MXF Descriptive Metadata Schemes 8 Version Number 01h Registry Version in which the specific key fi
25、rst appeared 912 See Table 22 of SMPTE ST 377-1 Generic Key for MXF Descriptive Metadata Schemes 13 Structure / Scheme Kind 05h EIDR Descriptive Metadata Scheme 14 Set 01h EIDR DM Framework 15 Reserved 00h 16 Reserved 00h 4.3.2 Set The EIDR DM Framework Set shall be as specified in Table 3. Table 3
26、DM Framework Set Item Name Type Item Designator Local Tag Length Req Value EIDR DM Framework Set Key 16 Req As specified in Table 2 Length BER Length var Req All items in the Descriptive Framework specified in SMPTE ST 377-1 EIDR DMS Essence ID Canonical EIDR Identifier Type (see SMPTE RP 2079) 06.0
27、E.2B.34. 01.01.01.0E. 01.01.15.14. 00.00.00.00 Dyn var Req EIDR Identifier for the essence associated with the DM Framework The EIDR DM Framework Set may be extended by the addition of items, including Strong or Weak References to one or more Descriptive Metadata Objects (DM Object.) Note: Canonical
28、 EIDR Identifier Type is specified in SMPTE RP 2079. It is derived from CanonicalDOINameType, which is itself derived from UTF16String type. 5 Basic Application This Section specifies the Basic Application of the EIDR DM Scheme that applies when a single EIDR Identifier is associated with an output
29、timeline of an MXF file. Other specifications or future revisions of this specification may specify additional applications of the EIDR DM Scheme. SMPTE RP 2089:2014 Page 6 of 6 pages P r e f a c e M a t e r i a l P a c k a g eS t a t i c T r a c k ( D M )S e q u e n c e ( D M )T r a c k sS t a t i
30、c T r a c k ( D M )S t a t i c T r a c k ( D M )Z e r o o r m o r e o t h e r t r a c k sS e q u e n c eS t r u c t u r a l C o m p o n e n t sD M S e g m e n tD M F r a m e w o r kE I D R F r a m e w o r k S e tD M S c h e m e s C o n t a i n s o n e i n s t a n c e o f t h e E I D R D M S c h e m
31、e L a b e l Figure 1 Basic Application of the EIDR DM Scheme (Informative) As illustrated in Figure 1, if a single EIDR Identifier is associated with an output timeline of an MXF file, the Tracks items of the corresponding Material Package shall reference a Static Track (DM) conforming to the follow
32、ing: The Sequence item of the Static Track (DM) shall reference a Sequence (DM). The Structural Components item of the Sequence (DM) shall reference one and only one DM Segment. The DM Segment shall conform to the following: o The Track IDs item shall be omitted; o The DM Framework item shall refere
33、nce one and only one EIDR DM Framework Set as specified in Section 4.3. Note: The Simple DM Plug-In Instance Removability specified in SMPTE ST 377-1 can be used to facilitate removal of the EIDR DM Framework instances. Additional EIDR DM Framework Sets, and hence EIDR Identifiers, may be associated with other aspects of the file, as provided in SMPTE ST 377-1.
