SMPTE ST 429-9-2014 D-Cinema Packaging - Asset Mapping and File Segmentation.pdf

1、 Approved November 24, 2014 Copyright by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Table of Contents Page Foreword . 2 Intellectual Property 2 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 Overview . 4 4.1 Ingesting

2、a Mapped File Set (Informative) 5 4.2 XML File Structure 5 5 AssetMap Structure . 6 5.1 Id . 6 5.2 AnnotationText optional 7 5.3 Creator 7 5.4 VolumeCount 7 5.5 IssueDate 7 5.6 Issuer 7 5.7 AssetList 7 6 Asset Structure 7 6.1 Id . 8 6.2 AnnotationText optional 8 6.3 PackingList optional 8 6.4 ChunkL

3、ist 8 7 Chunk Structure 8 7.1 Path . 9 7.2 VolumeIndex optional . 9 7.3 Offset optional . 9 7.4 Length optional 9 8 VolumeIndex Structure 9 Page 1 of 18 pages SMPTE ST 429-9:2014 Revision of SMPTE 429-9-2007 SMPTE STANDARD D-Cinema Packaging Asset Mapping and File Segmentation SMPTE ST 429-9:2014 Pa

4、ge 2 of 18 pages 9 Media-Specific Constraints 10 9.1 Mapped File Set Definition 10 9.2 Path URI 10 9.3 XML Encoding . 10 9.4 Asset Map Location . 10 10 Asset Map Sample (Informative) . 11 11 XML Schema 12 Annex A Basic Map Profile v2 (Normative) 14 A.1 Mapped File Set Definition 14 A.2 Path . 14 A.3

5、 XML Encoding . 14 A.4 Asset Map Location . 14 A.5 Example Ingest Algorithm (Informative) . 15 Annex B XML Diagram Legend (Informative) . 16 B.1 Element Symbols 16 B.2 Model Symbols (“Compositors“) . 17 B.3 Types . 17 B.4 Model Groups and References . 18 Foreword SMPTE (the Society of Motion Picture

6、 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 Practices and Engine

7、ering 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 are drafted in acc

8、ordance with the rules given in its Standards Operations Manual. SMPTE ST 429-9 was prepared by Technology Committee 21DC. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Standard. However, attention

9、 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. SMPTE ST 429-9:2014 Page 3 of 18 pages 1 Scope This document specifies a generic method of mapping asset ide

10、ntifiers (UUID) to locations (URI). An application of the method to common hierarchical filesystems, the Basic Map Profile v2, is specified. Note: Earlier versions of this specification allowed assets to be split among multiple volumes. This functionality was not found to be useful in practice and i

11、s removed from this version. The schema remains however unchanged to minimize impact on implementations. 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

12、text 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“

14、indicate 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 no

15、t 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” a

16、nd in addition indicates that the provision will never be defined in the future. 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 standar

17、ds are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE ST 429-8:2007, D-Cinema Packaging Packing List Internet Engineering Task Force (IETF) (2005, January)

18、. RFC 3986 Uniform Resource Identifiers (URI): Generic Syntax Internet Engineering Task Force (IETF) (2005, July). RFC 4122 A Universally Unique Identifier (UUID) URN Namespace. World Wide Web Consortium (W3C) (2004, February 4). Extensible Markup Language (XML) 1.0 (Third Edition). World Wide Web C

19、onsortium (W3C) (2004, October 28). XML Schema Part 1: Structures (Second Edition). World Wide Web Consortium (W3C) (2004, October 28). XML Schema Part 2: Datatypes (Second Edition). World Wide Web Consortium (W3C) (2009, December 8). Namespaces in XML, SMPTE ST 429-9:2014 Page 4 of 18 pages 4 Overv

20、iew The packing list SMPTE ST 429-8 specifies the contents of a distribution package. The package and its Packing List are specified independently of the underlying media, e.g. hard disk partition. The Packing List contains the UUID identifiers of the assets in the Package, not the location of those

21、 assets on the underlying media. The Asset Map provides the link between the asset identifier UUIDs and the files containing the assets. This layered approach has two distinct advantages. First, it simplifies specification of the Packing List by removing dependence on past, current or future media f

22、ormats and constraints. Second, it allows the package and its underlying assets to be created once and mapped onto various target media as circumstances require. The Asset Map structure, depicted in Figure 1, provides a mapping from the Packing List Id and asset Ids to actual locations within a Mapp

23、ed File Set, which consists of the Asset Map and all referenced assets. An Asset Map can contain mappings for more than one package, but does not contain a partial mapping for a particular package. The Asset Map provides special identification for Packing List assets so that they can be located with

24、out scanning all assets within the package. Figure 1 Relationship between the Packing List and Asset Map structures The definition of Mapped File Set and the means of locating the Asset Map are defined by a normative Map Profile (see Section 9) for that media type. Annex A specifies a Map Profile fo

25、r use with common hierarchical filesystems. SMPTE ST 429-9:2014 Page 5 of 18 pages 4.1 Ingesting a Mapped File Set (Informative) The process of reading a package by an implementation is termed ingest. A system can provide a simple or elaborate ingest control interface allowing coarse or fine-grained

26、 selection of items to be ingested but the basic process will typically be the same. As illustrated using pseudo-code in Figure 2, a Mapped File Set is ingested by first opening its Asset Map document. The means of identifying the Asset Map on the Mapped File Set is defined by the normative Map Prof

27、ile (see Section 9) for that media type. The Asset Map is used to locate the Packing List(s) which detail the contents of the available package(s). Assets are chosen from the Packing List(s), and the selected assets are ingested. Ingest Mapped File Set: open the Asset Map for each Packing List in th

28、e Asset Map open the Packing List for each Asset in the Packing List if this Asset is wanted locate the corresponding Asset structure in the Asset Map read the Asset and test the message digest Figure 2 Example ingest process 4.2 XML File Structure The structures defined in this document are represe

29、nted using the Extensible Markup Language (XML) XML 1.0, and specified using XML Schema XML Schema Part 1: Structures and XML Schema Part 2: Datatypes. This specification shall be associated with a unique XML namespace name Namespaces in XML. The namespace name shall be the string value “http:/www.s

30、mpte-ra.org/schemas/429-9/2007/AM“. This namespace name conveys both structural and semantic version information, but does not serve the purpose of a traditional version number field. Table 1 lists the XML namespace names used in this specification. Namespace names are represented as Uniform Resourc

31、e Identifier (URI) values RFC 39861. 1 Readers unfamiliar with URI values as XML namespace names should be aware that although a URI value begins with a “method” element (“http” in this case), the value is designed primarily to be a unique string and does not necessarily correspond to an actual on-l

32、ine resource. Applications implementing this standard should not attempt to resolve URI values on-line. SMPTE ST 429-9:2014 Page 6 of 18 pages Table 1 XML Namespaces Qualifier URI am http:/www.smpte-ra.org/schemas/429-9/2007/AM xs http:/www.w3.org/2001/XMLSchema The URIs found in Table 1 are normati

33、ve. The namespace qualifier values (also called namespace prefixes in XML jargon) used in Table 1 and elsewhere in this document, namely “am“ and “xs“, are not normative. Specifically, they may be replaced in instance documents by any XML compliant namespace prefix. In other words, implementations s

34、hall expect any arbitrary XML compliant namespace prefix value that is associated with a URI from Table 1. 5 AssetMap Structure An Asset Map document is an XML document with an AssetMap element as its root element. The elements and structure of an AssetMap element are illustrated in Figure 3 and def

35、ined in the subsections that follow. An Asset Map may contain mappings for more than one package, but shall not contain a partial mapping for a particular package, i.e. a package shall not span multiple distinct Asset Maps. A Mapped File Set shall contain exactly one Asset Map. Figure 3 AssetMap str

36、ucture 5.1 Id The Id element uniquely identifies the Asset Map structure. It is encoded as a urn:UUID RFC 4122. SMPTE ST 429-9:2014 Page 7 of 18 pages 5.2 AnnotationText optional The AnnotationText element is a free-form, human-readable annotation describing the Asset Map. It is meant strictly as a

37、display hint to the user. The optional language attribute is an xs:language language code and indicates the language used. If the language attribute is not present, the default value en shall be used. 5.3 Creator The Creator element is a free-form, human-readable annotation describing the system (ha

38、rdware/software) that was used to create the Asset Map for distribution. It is meant strictly as a display hint to the user. The optional language attribute is an xs:language language code and indicates the language used. If the language attribute is not present, the default value en shall be used.

39、5.4 VolumeCount The VolumeCount element shall be 1 (one). Note: Earlier versions of this specification included support for distributing Asset Maps across multiple storage volumes. 5.5 IssueDate The IssueDate element indicates the time and date at which the Asset Map was issued. It may be displayed

40、to the user. 5.6 Issuer The Issuer element is a free-form, human-readable annotation describing the person or company who has created the Asset Map for distribution. It is meant strictly as a display hint to the user. The optional language attribute is an xs:language language code and indicates the

41、language used. If the language attribute is not present, the default value en shall be used. 5.7 AssetList The AssetList element contains a list of Asset elements. The structure of the Asset element is described in the following section. 6 Asset Structure The Asset element is used to represent asset

42、s within the AssetList element of an AssetMap. The Asset element is of the type AssetType, illustrated in Figure 4 and defined in the subsections that follow. SMPTE ST 429-9:2014 Page 8 of 18 pages Figure 4 Asset structure 6.1 Id The Id element uniquely identifies the asset for management purposes.

43、It is encoded as a urn:UUID RFC 4122. 6.2 AnnotationText optional The AnnotationText element is a free-form, human-readable annotation describing the asset. It is meant strictly as a display hint to the user. The optional language attribute is an xs:language language code and indicates the language

44、used. If the language attribute is not present, the default value en shall be used. 6.3 PackingList optional The PackingList element indicates whether the asset is a Packing List SMPTE ST 429-8. It is encoded as an xs:boolean. If the asset is a Packing List, the element shall be present and the valu

45、e shall be true, otherwise the element shall be absent or its value shall be false. The default value is false. 6.4 ChunkList The ChunkList element shall contain one Chunk element, which provides information on the location of the asset. The structure of the Chunk element is described in the followi

46、ng section. Note: Earlier versions of this specification included support for segmenting assets across multiple chunks. This version requires that the asset is contained in a single chunk. 7 Chunk Structure The Chunk element is used to represent chunks within the ChunkList element of an Asset. The C

47、hunk element is of the type ChunkType, illustrated in Figure 5 and defined in the subsections that follow. SMPTE ST 429-9:2014 Page 9 of 18 pages Figure 5 Chunk structure 7.1 Path The Path element indicates the complete path for the Chunk, represented as a URI per RFC 3986. Its semantics and format

48、are delivery-medium dependent, and constrained by each Map Profile (see Section 9). The value is encoded as an xs:anyURI. Note: Annex A presents a basic Map Profile. 7.2 VolumeIndex optional The VolumeIndex element shall be equal to 1 or absent. Note: Earlier versions of this specification included

49、support for distributing Asset Maps across multiple storage volumes 7.3 Offset optional The Offset element shall be equal to 0 or absent. Note: Earlier versions of this specification supported segmentation of assets in multiple chunks to address filesystems with file size limits. 7.4 Length optional The Length element identifies the length, in bytes, of the chunk. It shall be absent, or equal to the length in bytes of the asset. Note: Earlier