SMPTE ST 429-8-2007 D-Cinema Packaging Packing List.pdf

《SMPTE ST 429-8-2007 D-Cinema Packaging Packing List.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 429-8-2007 D-Cinema Packaging Packing List.pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、 Copyright 2007 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved June 25, 2007 Table of Contents Page Forward . 2 1 Scope 2 2 Conformance Notation 2 3 Normative References 2 4 Overview . 3 4.1 Use of XML Language 5 5 Pack

2、agingList Structure 6 5.1 Id . 7 5.2 AnnotationText optional 7 5.3 IconId optional. 7 5.4 IssueDate 7 5.5 Issuer 7 5.6 Creator 7 5.7 GroupId optional 7 5.8 AssetList 8 5.9 Signer optional 8 5.10 Signature optional . 8 6 Asset Structure 9 6.1 Id . 9 6.2 AnnotationText optional 9 6.3 Hash 10 6.4 Size

3、. 10 6.5 Type 10 6.6 OriginalFileName optional. 10 7 XML Schema. 11 7.1 PackingList 11 7.2 Asset . 11 7.3 Misc. 12 Annex A Sample (Informative) 13 Annex B XML Diagram Legend (Informative) . 14 B.1 Element Symbols 14 B.1.1 Examples. 14 B.2 Model Symbols (“Compositors“). 15 B.3 Types 15 B.4 Model Grou

4、ps and References. 16 Annex C Bibliography (Informative) 17 Page 1 of 17 pages SMPTE 429-8-2007 SMPTE STANDARD D-Cinema Packaging Packing List SMPTE 429-8-2007 Page 2 of 17 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards develo

5、ping 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 Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participatio

6、n 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 accordance with the rules given in Part XIII of its Administrative Practices. S

7、MPTE 429-8 was prepared by Technology Committee DC28. 1 Scope This standard specifies the data format for interchange of a Packing List for Digital Cinema applications. The electronic or physical form of a complete package described by a Packing List is beyond the scope of this standard. 2 Conforman

8、ce 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 not indispensable, and can be removed, changed, or added e

9、ditorially 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 individual paragraphs that start with “Note:” The keywords “sha

10、ll“ 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 recommended as particularly suitable, without mentioning or exclu

11、ding 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 courses of action permissible within the limits of the docu

12、ment. 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 defined in the future. 3 Normative References The followin

13、g 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 are subject to revision, and parties to agreements based on this recommended practice are encouraged

14、to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE 429-8-2007 Page 3 of 17 pages 1. World Wide Web Consortium (W3C) (2004, February 4). Extensible Markup Language (XML) 1.0 (Third Edition). 2. World Wide Web Consortium (W3C) (2004, October 28).

15、 XML Schema Part 1: Structures (Second Edition). 3. World Wide Web Consortium (W3C) (2004, October 28). XML Schema Part 2: Datatypes (Second Edition). 4. World Wide Web Consortium (W3C) Recommendation (12 February 2002). XML-Signature Syntax and Processing. 5. Internet Engineering Task Force (IETF)

16、RFC3174 (September 2001) US Secure Hash Algorithm 1 6. Internet Engineering Task Force (IETF) RFC2045 (November 1996) Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies 7. Internet Engineering Task Force (IETF) RFC2046 (November 1996) Multipurpose Internet Mail

17、Extensions (MIME) Part Two: Media Types 8. Internet Engineering Task Force (IETF) (1996, November). RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax. 9. Internet Engineering Task Force (IETF) (2005, July). RFC 4122 A Universally Unique Identifier (UUID) URN Namespace. 10. Internet Enginee

18、ring Task Force (IETF) (2001, April) RFC 4051 Additional XML Security Uniform Resource Identifiers (URIs). 4 Overview The packing list specifies the contents of a distribution package. A distribution package shall contain one packing list together with Composition Playlist assets, essence assets and

19、 other assets as needed to complete the package. The packing list has a list of elements that define the distribution package together with a list of references to all the assets in the package. This list contains the Ids that uniquely identify each asset in the package. Figure 1 illustrates the abs

20、tract form of a complete package for a trailer and a single reel feature. SMPTE 429-8-2007 Page 4 of 17 pages Figure 1 Typical Distribution Package (Informative) Figure 2 illustrates the abstract form of a partial Packing List, in which a replacement “reel” is being sent to theatres. This may be cre

21、ated, for example, to distribute a change in the end credits of a feature. Note that this partial package includes picture, sound and subtitle track files, and a Composition Playlist file that references those files as well as files from a previously delivered package. The example package shown in F

22、igure 2 is not related to the example package shown in Figure 1. SMPTE 429-8-2007 Page 5 of 17 pages Figure 2 Typical Partial Distribution Package (Informative) 4.1 Use of XML Language The structures defined in this document are represented using the Extensible Markup Language (XML) XML 1.0, and spe

23、cified using XML Schema XML Schema Part 1: Structures and Datatypes 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.smpte-ra.org/schemas/429-8/2007/PKL”. This namespace na

24、me conveys both structural and semantic version information, and serves 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 Resource Identifier (URI) values RFC 23961. Table 1 XML Namespaces Q

25、ualifier URI pkl http:/www.smpte-ra.org/schemas/429-8/2007/PKL xs http:/www.w3.org/2001/XMLSchema ds http:/www.w3.org/2000/09/xmldsig# The URIs found in Table 1 are normative. The namespace qualifier values (also called namespace prefixes in XML jargon) used in Table 1 and elsewhere in this document

26、, namely “pkl“, “xs“ and “ds”, are not normative. Specifically, they may be replaced in instance documents by any XML compliant namespace prefix. In other words, implementations shall expect any arbitrary XML compliant namespace prefix value that is associated with a URI from table 1. 1Readers unfam

27、iliar 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-line resource. Applications implementing this standar

28、d should not attempt to resolve URI values on-line. SMPTE 429-8-2007 Page 6 of 17 pages Datatypes from other schemas that are used in this document will be prefixed with the appropriate namespace qualifier (e.g., xs:dateTime). See XML Schema Part 2: Datatypes and XML-Signature Syntax and Processing

29、for further information about these types. The MIME type IETF RFC 2046 for a document containing a single PackingList element as its root shall be “text/xml”. 5 PackingList Structure A Packing List shall be encoded as an XML document XML 1.0. The top-level element shall be designated PackingList, an

30、d is described in Figure 3. Figure 3 Packing List structure. Dotted lines denote an optional element. SMPTE 429-8-2007 Page 7 of 17 pages 5.1 Id The Id element uniquely identifies the packing list for asset management purposes. Each unique Packing List shall have a distinct Id. This will allow easy

31、differentiation between Packing Lists. The Id shall be encoded as a urn:UUID RFC 4122. 5.2 AnnotationText optional The AnnotationText element shall be a free-form, human-readable annotation describing the distribution package. It is meant strictly as a displayed guidance for the user. The optional l

32、anguage attribute is an xs:language language code and indicates the language of the content of the element. If the language attribute is not present, the default value en shall be used. 5.3 IconId optional The IconId element uniquely identifies an external image resource containing a picture icon il

33、lustrating the Packing List. The icon may be rendered, for instance, from a frame of the underlying content. The IconId parameter shall be encoded as a urn:UUID RFC 4122. The mapping of UUID values to actual image resources is beyond the scope of this document. 5.4 IssueDate The IssueDate element in

34、dicates the time and date at which the Packing List was issued. The IssueDate shall be encoded as an xs:dateTime value. 5.5 Issuer The Issuer element shall be a free-form, human-readable annotation describing the person or company that created the Packing List. It is meant strictly as a displayed gu

35、idance for the user. The optional language attribute is an xs:language language code and indicates the language of the content of the element. If the language attribute is not present, the default value en shall be used. 5.6 Creator The Creator element shall be a free-form, human-readable annotation

36、 describing the person, facility or system (hardware/software) that created the Packing List. It is meant strictly as a displayed guidance for the user. The optional language attribute is an xs:language language code and indicates the language of the content of the element. If the language attribute

37、 is not present, the default value en shall be used. 5.7 GroupId optional The GroupId element is used to create associations between packages. When present, the element shall contain a urn:UUID value RFC 4122. The presence of the element shall indicate to a receiver that the package may be associate

38、d for asset management purposes with any other package containing the same GroupId value. The exact meaning of the association is beyond the scope of this document, but in general a packing list with no GroupId element should contain a complete set of assets (i.e., there are no unresolved references

39、 between assets). Two or more packing lists with matching GroupId elements should contain assets that are related (e.g., referentially). SMPTE 429-8-2007 Page 8 of 17 pages 5.8 AssetList The AssetList element contains the list of Asset elements contained in the package. The structure of the Asset el

40、ement is described in Section 6 of this document. The order of Asset elements in the list shall not be significant. 5.9 Signer optional The Signer element uniquely identifies the entity, and hence the public-private key pair that digitally signed the Packing List. It shall be an instance of the KeyI

41、nfoType type defined in XML Signature Syntax And Processing. If the Signer element is present, then the Signature element shall also be present. If X.509 certificates are used per XML-Signature Syntax and Processing, then the Signer element shall contain one X509Data element containing one X509Issue

42、rSerial element, which uniquely identifies the certificate used to sign the Packing List. 5.10 Signature optional The Signature element shall contain a digital signature authenticating the Packing List. If the Signature element is present, then the Signer element (see 5.9, above) shall also be prese

43、nt. The Signature element shall be an instance of the ds:Signature element defined in the XML Signature Syntax and Processing. The digital signature shall be enveloped and apply to the entire Packing List. An enveloped signature is one that is attached to the document being signed. The signature is

44、generated by the signer, as identified by the Signer element, using the signers private key. The standard Signature element is a highly flexible construct, which can adapt to a wide range of applications. For the purpose of the Packing List, it shall satisfy the following constraints: The KeyInfo el

45、ement shall be present and shall contain the entire certificate chain for the signer. The Object element shall not be present and the URI attribute of the Reference element shall set to “” (empty string), as the signature is enveloped. The Reference element shall contain a single DigestMethod elemen

46、t, with its Algorithm attribute set to the URI value http:/www.w3.org/2000/09/xmldsig#sha1. The Reference element shall contain a single Transform element, with its Algorithm attribute set to the URI value http:/www.w3.org/2000/09/xmldsig#enveloped-signature. The CanonicalizationMethod shall be set

47、to the URI value http:/www.w3.org/TR/2001/REC- xml-c14n-20010315. The SignatureMethod shall be set to the URI value http:/www.w3.org/2001/04/xmldsig- more#rsa-sha256 RFC 4051. If X.509 certificates are used per XML-Signature Syntax and Processing, then the entire certificate chain shall be carried i

48、n the KeyInfo element as a sequence of X509Data elements. Each of the X509Data elements shall correspond to one certificate in the chain, and shall contain one X509IssuerSerial element and one X509Certificate element. SMPTE 429-8-2007 Page 9 of 17 pages 6 Asset Structure A Packing List contains a li

49、st of assets. An asset is a set of data, such as essence or metadata. Any type of data may be referred to as an asset. Each asset shall be described by an Asset element as described in Figure 4. See the XML Schema declaration in Section 7 of this document for explicit type information. Figure 4 Asset Structure. Dotted lines denote an optional element. 6.1 Id The Id element uniquely identifies the asset for management purposes. It shall be enco