1、Access to Content for (SMPTE ST 2067-3:2016) (Click here to view the publication) This Page is not part of the original publication: This page has been created by IHS as a convenience to the user in order to provide access to the content as authorized by the Copyright holder of this document. Click
2、the link(s) below to access the content and use normal procedures for downloading or opening the files. SMPTE_Additional Data Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer e.g., for playout or transcoding. It is an extensible, human-readable
3、structure designed for file-based operations. 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 n
4、ot 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 indivi
5、dual 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 recommen
6、ded 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 co
7、urses 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 be d
8、efined 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 implem
9、ent 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 language
10、forms. 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 to revision, and parties to agreements based on this recomm
11、ended practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. 1) SMPTE ST 12-1:2008 SMPTE ST 12-1:2008, Television Time and Control Code SMPTE ST 433 SMPTE ST 433:2008 D-Cinema XML Data Types SMPTE ST 2067-3:2016 Page 6 of 33 pages
12、 RFC 2045 Internet Engineering Task Force (IETF) (November 1996). RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies RFC 2046 Internet Engineering Task Force (IETF) RFC2046 (November 1996) Multipurpose Internet Mail Extensions (MIME) Part Two: Media Typ
13、es RFC 2141 Internet Engineering Task Force (IETF) (May 1997) RFC 2141 URN Syntax RFC 2396 Internet Engineering Task Force (IETF) (November 1996). RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax RFC 4634 Internet Engineering Task Force (IETF) (July 2006). RFC 4634 US Secure Hash Algorith
14、ms (SHA and HMAC-SHA) RFC 5646 Internet Engineering Task Force (IETF) (September 2009). RFC 5646 Tags for Identifying Languages XML World Wide Web Consortium (W3C) (4 February 2004). Extensible Markup Language (XML) 1.0 (Third Edition) XML Namespaces World Wide Web Consortium (W3C) (8 December 2009)
15、. Namespaces in XML 1.0 (Third Edition) XML Schema Part 1: Structures World Wide Web Consortium (W3C) (28 October 2004). XML Schema Part 1: Structures (Second Edition) XML Schema Part 2: Datatypes World Wide Web Consortium (W3C) (28 October 2004). XML Schema Part 2: Datatypes (Second Edition) XML Di
16、gital Signature World Wide Web Consortium (W3C) (12 February 2002). XML-Signature Syntax and Processing 1) Note: The reference to the superseded version of this standard is intentional. The current version was not reviewed by the Technical Committee to verify if it is appropriate for use with this d
17、ocument. 4 Glossary 4.1 Asset: Metadata or essence underlying a Resource. A Track File is one kind of Asset. 4.2 Composition: Embodies a version of a complete work, combining metadata and essence. 4.3 Edit Rate: A number of Edit Units to be reproduced per second. 4.4 Edit Unit: The smallest temporal
18、 increment of access to a timeline. 4.5 Essence: Content, e.g. image, audio or data essence, meant for presentation. 4.6 IMF: Acronym for Interoperable Master Format. 4.7 Main Titles: A credit sequence generally shown near the beginning of a motion picture. 4.8 Metadata: Data about data or data desc
19、ribing other data. Information that is considered ancillary to or otherwise directly complementary to essence. Information that is useful or of value when associated with the essence being provided. 4.9 MXF: Material Exchange Format. SMPTE ST 2067-3:2016 Page 7 of 33 pages 4.10 Native Duration: The
20、total number of Resource Edit Units in an Asset. 4.11 Native Start Point: The first Edit Unit of an Asset. 4.12 Playable Region: A contiguous sequence of Resource Edit Units within an Asset that is intended to be reproduced. An Asset can contain Edit Units before and/or after the Playable Region. 4.
21、13 Resource: A portion of an Asset selected for reproduction on the Composition timeline. 4.14 Sequence: An ordered collection of Resources to be reproduced sequentially. 4.15 Segment: A collection of Sequences intended to be reproduced in parallel. 4.16 Track File: An Asset consisting of a file con
22、taining essence of a single kind, e.g. as audio, image or data essence. 4.17 UUID: Acronym for Universal Unique Identifier. 4.18 XML: Acronym for extensible Markup Language. 5 Instance A Composition Playlist instance shall be an XML document, as specified in XML, that consists of a single Compositio
23、nPlaylist element (see Section 6.1). 5.1 Schema Each Composition Playlist instance shall conform to the XML schema definitions (see XML Schema) found in this specification. In the event of a conflict between schema definitions and the prose, the prose shall take precedence. Table 1 specifies the XML
24、 schema root element. Table 1 XML Schema root element definition The namespace prefixes used in XML Schema definitions herein are not normative values and implementations shall perform correctly with any XML compliant prefix values. The XML Schema definitions found in this specification include elem
25、ents specified in XML Digital Signature and SMPTE ST 433. A schema instance that consolidates all inline schema definitions made in this document is provided for convenience in Annex B. In case of conflict, the schema definitions included herein shall take precedence. SMPTE ST 2067-3:2016 Page 8 of
26、33 pages 5.2 Character Encoding Composition Playlist instances shall be encoded using the UTF-8 character encoding. 5.3 MIME Type The MIME type, as defined in IETF RFC 2046, of a Composition Playlist instance shall be text/xml. 5.4 Structure Versioning The target namespace specified in Section 5.1,
27、i.e. the value of the targetNamespace attribute of the schema element, shall only be used by Composition Playlist instances that conform to this specification as expressed by the combination of its prose and schema definitions. Instances using specifications that modify the schema definitions or the
28、 semantics of the elements defined herein, including future versions of this specification, shall use a different namespace and no two distinct schemas shall have the same target namespace. As such, the target namespace allows implementations to unambiguously identify the defining specification of a
29、 Composition Playlist instance. 6 Structure In order to avoid duplication between text and schema, the cardinality and default values of elements are specified in the schema only. 6.1 CompositionPlaylistType Table 2 CompositionPlaylistType schema definition SMPTE ST 2067-3:2016 Page 9 of 33 pages 6.
30、1.1 Id The Id element shall uniquely identify the Composition Playlist instance. Any two Composition Playlist instances may have identical Id values if and only if the two Composition Playlist instances are identical. 6.1.2 Annotation The Annotation element shall be a free-form, human-readable annot
31、ation describing the composition. It is meant strictly as a display hint to the user. 6.1.3 IssueDate The IssueDate element shall indicate the time and date at which the Composition Playlist was issued. 6.1.4 Issuer The Issuer element shall be a free-form, human-readable annotation that identifies t
32、he entity that created the Composition Playlist. It is meant strictly for display to the user. Note: The Signer element defined in Section 6.1.17 is used to identify the entity that digitally signed the Composition Playlist. 6.1.5 Creator The Creator element shall be a free-form, human-readable anno
33、tation that identifies the device or software program used to create the Composition Playlist, the facility that created the Composition Playlist and the operator that created the Composition Playlist. It is meant strictly for display to the user. SMPTE ST 2067-3:2016 Page 10 of 33 pages 6.1.6 Conte
34、ntOriginator The ContentOriginator element shall be a free-form, human-readable annotation that identifies the originator of the content underlying the composition, as opposed to the Issuer, which identifies the entity that created the Composition Playlist. It is meant strictly for display to the us
35、er. 6.1.7 ContentTitle The ContentTitle element shall contain a human-readable title for the composition, e.g. The Jazz Singer. It is strictly meant as a display hint to the user. 6.1.8 ContentKind The ContentKind element shall be human-readable and indicate the kind of work represented by the Compo
36、sition. ContentKindType is defined in Section 6.4. The scope attribute of the ContentKind element shall determine the permissible values of the ContentKind element: if the scope attribute is absent from the ContentKind element, or set to its default value, the value of the ContentKind element shall
37、match one of the values listed in Table 3; if the scope attribute is present and equal to “http:/www.smpte-ra.org/schemas/2067-3/2016#content-kind“, the value of the ContentKind element shall match one of the values listed in Table 4; otherwise, the value of the ContentKind element is outside the sc
38、ope of this specification. In any case, this element is intended to be displayed to the user. Table 3 Permitted Content Kind values under the default scope Kind Description advertisement Content promoting a product or service other than an upcoming feature. feature A theatrical feature. psa Public s
39、ervice announcement. rating Slate/still image indicating the recommended age group permitted to view the content to follow. This rating is generally unique per country. short Non advertising/promotional content (3 to 15 minutes) typically before a theatrical feature. teaser Very short (typically les
40、s than 1 minute) content promoting an upcoming theatrical feature. test Content used to test, calibrate or setup equipment. trailer Short (2 to 3 minutes) content promoting an upcoming theatrical feature. transitional Extremely short content (1 to 15 seconds) separating unrelated compositions. episo
41、de Part of a dramatic work such as a serial television program. highlights Edited sequence of one or more memorable parts of an event, feature, episode or period of time. event Activity that happens at a given place and time, especially one of importance, including a music performance, a contest mak
42、ing up a sports competition. SMPTE ST 2067-3:2016 Page 11 of 33 pages Table 4 Additional Content Kind values Kind Description supplemental Content created as extra material for a feature or episode such as behind the scenes material or deleted scenes. documentary A program that contains factual info
43、rmation based on real world events and/or people. 6.1.9 ContentVersionList All ContentVersion elements within the ContentVersionList element shall be synonyms that uniquely identify the content represented by the Composition Playlist. This is in contrast with the Id element, specified in Section 6.1
44、.1 , which identifies a particular instance of the Composition Playlist. No two ContentVersion elements shall have identical Id elements. Two Composition Playlist instances shall be assumed to refer to the same content if they have in common at least one Id element of a ContentVersion element. This
45、specification makes no assumption of the definition of “same content“, which is left to the issuer of the Composition Playlist instance. The element may be used to extend ContentVersion elements. Implementations shall ignore any such elements from a namespace it does not recognize. ContentVersionTyp
46、e is defined in Section 6.8. 6.1.10 EssenceDescriptorList The information provided by the EssenceDescriptorList element is intended to assist users in scheduling and tracking content. In case of a conflict between an EssenceDescriptor element and descriptive information in the underlying Track File,
47、 the latter shall take precedence. Implementations should not rely on this information for transcoding or playout. 6.1.10.1 EssenceDescriptor Each EssenceDescriptor element of the EssenceDescriptorList element shall be a human-readable representation of selected descriptive information present in on
48、e or more Track Files. Collectively these EssenceDescriptor elements describe the essence referred to by the composition. Each EssenceDescriptor shall be referenced through its Id element by at least one Resource of type derived from TrackFileResource see Section 6.12.1. For example, given a composi
49、tion referencing one stereo and one 5.1 audio Track File, there would be at least two audio EssenceDescriptor elements. Each of the Resources referencing either of two Track Files would reference the corresponding EssenceDescriptor element through the SourceEncoding element. The defining specification of each Track File referenced by the Composition Playlist shall specify the content of its associated EssenceDescriptor element and the process by which it is populated. Specifically, it shall specify the elements, if any, that
