SMPTE ST 430-14-2015 D-Cinema Operations - Digital Sync Signal and Aux Data Transfer Protocol.pdf

《SMPTE ST 430-14-2015 D-Cinema Operations - Digital Sync Signal and Aux Data Transfer Protocol.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 430-14-2015 D-Cinema Operations - Digital Sync Signal and Aux Data Transfer Protocol.pdf（27页珍藏版）》请在麦多课文档分享上搜索。

1、 Approved August 1, 2015 Copyright 2015 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 SMPTE ST 430-14:2015 SMPTE STANDARD D-Cinema Operations Digital Sync Signal and Aux Data Transfer Protocol Page 1 of 27 pages Table of Contents For

2、eword . 2 Intellectual Property . 2 Introduction 2 1 Scope . 6 2 Conformance Notation 6 3 Normative References 7 4 Terms and Definition 8 5 Synchronization Signal . 9 6 Transfer Protocol 19 Annex A Using Primary Picture Output Offset and Primary Picture Screen Offset (Informative) . 26 SMPTE ST 430-

3、14:2015 Page 2 of 27 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 America, SMPTE has members in over 80 countries on six continents. SMPTEs Engi

4、neering 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. SMPTE cooperates closely with other standards-developing organizations, i

5、ncluding ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. SMPTE ST 430-14 was prepared by Technology Committee 21DC. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent r

6、ights essential to the implementation of this Engineering 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 sect

7、ion is entirely informative and does not form an integral part of this Engineering Document. Figure 1 Overview of the Aux Data Synchronization Signal and Transfer Protocol Architecture P r o c e s s o rA E S / E B UE m i t t e r ( e . g . I m a g e M e d i a B l o c k )S e r v e r L A NA u x D a t a

8、T r a c k F i l eD a t a I t e mD a t a I t e mS y n c h r o n i z a t i o n S i g n a lS M P T E S T 4 3 0 - 1 0 D C SL A NA u x i l i a r y C o n t e n t S y n c h r o n i z a t i o n P r o t o c o lH T T PSMPTE ST 430-14:2015 Page 3 of 27 pages As illustrated in Figure 1, this document specifies

9、a Transfer Protocol that allows Data Items, as specified SMPTE ST 429-14, to be transmitted to a Processor over the Local Area Network (LAN); and a generic Synchronization Signal that carries sufficient information to allow these Data Items to be reproduced by the Processor synchronously with Show p

10、layback. The source of the Data Items transmitted using the Transfer Protocol is called the Server, and the source of the Synchronization Signal is called the Emitter. The Processor discovers the Server by connecting to a Digital Cinema Server (DCS) entity using the Auxiliary Content Synchronization

11、 (ACS) protocol both DCS and ACS are specified in SMPTE ST 430-10. This specification allows the Server, Emitter and the DCS to be implemented on the same or different devices. A Processor can take many forms, including that of an Immersive Sound Processor or a Motion System Controller. The Synchron

12、ization Signal (see Section 5) is an audio sample-accurate binary signal generated by an Emitter, typically the Image Media Block, at time of playback and compatible with AES/EBU interfaces. It includes the current playback position within a timeline (see Figure 4) that consists of a sequence of con

13、tiguous Edit Units corresponding to the currently playing sequence of Compositions; i.e., the Show. The Transfer Protocol (see Section 6) uses the Hypertext Transfer Protocol (HTTP). It allows the Processor to request from a Server the Data Items of a specified kind (as determined by the Data Essenc

14、e Coding item of the Data Essence Descriptor) and corresponding to a position with the Timeline (determined from the Synchronization Signal). Figure 2 illustrates the interaction between Emitter, Server, DCS and Processor in a typical application. When a Show is selected and a valid Synchronization

15、signal is detected (with the Status flag set to Pause or Stopped), the Processor connects to the DCS and, using the Set RPL Location message, determines the Server network address (see Section 6.4). The Processor then buffers Data Items by making a number of requests (see Figure 3) to the Server. Wh

16、ile it is buffering, the Processor responds with ACS Busy to Get Status Requests issued by the DCS, indicating that it is not ready for playback. SMPTE ST 430-14:2015 Page 4 of 27 pages Figure 2 Transfer Protocol Sequence Diagram TimeE m i t t e r D C S P r o c e s s o rS e r v e rNoSyncSignalSyncSi

17、gnalPresent(Flags.0=0)S h o w # 1 S e l e c t e dC o n n e c tA n n o u n c e R e s p o n s eA n n o u n c e R e q u e s tG e t N e w L e a s e R e q u e s tS e t R P L L o c a t i o n R e s p o n s eG e t N e w L e a s e R e s p o n s eS e t R P L L o c a t i o n R e q u e s tG e t A u x D a t a E

18、d i t U n i t sA u x D a t a E d i t U n i t sG e t S t a t u s R e q u e s tG e t S t a t u s R e s p o n s e ( S t a t u s R e s p o n s e = A C S B u s y )G e t S t a t u s R e q u e s tG e t S t a t u s R e s p o n s e ( S t a t u s R e s p o n s e = R R P S u c c e s s f u l )SyncSignalPresent(

19、Flags.0=1)S h o w # 1 S t a r t sG e t A u x D a t a E d i t U n i t sA u x D a t a E d i t U n i t sS h o w # 2 E n d sNoSyncSignalSyncSignalPresent(Flags.0=0)S h o w # 2 S e l e c t e dG e t A u x D a t a E d i t U n i t sA u x D a t a E d i t U n i t sG e t A u x D a t a E d i t U n i t sA u x D

20、a t a E d i t U n i t sG e t S t a t u s R e q u e s tG e t S t a t u s R e s p o n s e ( S t a t u s R e s p o n s e = A C S B u s y )G e t S t a t u s R e q u e s tG e t S t a t u s R e s p o n s e ( S t a t u s R e s p o n s e = R R P S u c c e s s f u l )SyncSignalPresent(Flags.0=0)C u r r e n t

21、 E d i t U n i t , P l a y o u t I D , ( i n S y n c h r o n i z a t i o n S i g n a l )C u r r e n t E d i t U n i t , P l a y o u t I D , ( i n S y n c h r o n i z a t i o n S i g n a l )C u r r e n t E d i t U n i t , P l a y o u t I D , ( i n S y n c h r o n i z a t i o n S i g n a l )C u r r e

22、n t E d i t U n i t , P l a y o u t I D , ( i n S y n c h r o n i z a t i o n S i g n a l )S e t R P L L o c a t i o n R e s p o n s eS e t R P L L o c a t i o n R e q u e s tSMPTE ST 430-14:2015 Page 5 of 27 pages The start of Show playback is signaled by the Status flag of the Synchronization Sign

23、al (see Section 5.3.4) transitioning to Playing. While the Status flag remains equal to Playing, the Processor reproduces the Data Items it has obtained from the Server based on the Timeline Edit Unit Index carried by the Synchronization Signal. When playback of the first Show stops and a second Sho

24、w is selected, the Status flag of the Synchronization Signal transitions to Stopped, and the Processor stops playback and starts buffering. The Processor starts playback along the second Show timeline when the Status flag transitions to Playing again. Figure 3 Sample Transfer Protocol Request-Respon

25、se The minimal expected behavior of a Processor is specified in Section 5.7. The Synchronization Signal and Transfer Protocol are designed to work together. The Synchronization Signal can nevertheless be used without the Transfer Protocol; e.g., a Processor can use the Synchronization Signal to dete

26、rmine playback location within the current Show but use means other than the Transfer Protocol to obtain playback essence. The Transfer Protocol however requires the presence of the Synchronization Signal. SMPTE ST 430-14:2015 Page 6 of 27 pages 1 Scope This document specifies (i) a Transfer Protoco

27、l that allows Data Items from an Aux Data Track File to be transmitted to a Processor for reproduction, and (ii) a Synchronization Signal that allows a Processor to reproduce Data Items synchronously with the D-Cinema presentation. The Transfer Protocol uses the Hypertext Transfer Protocol (HTTP), w

28、hile the Synchronization Signal is a binary signal that is accurate to the nearest audio sample of the presentation, intended to be generated by the Image Media Block at time of playback, and for use with AES3 interfaces. While the Transfer Protocol requires the presence of the Synchronization Signa

29、l, the Synchronization Signal can be used in absence of the Transfer Protocol. 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 poten

30、tially 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, any section explicitly l

31、abeled 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“ indicate that, among sever

32、al 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 prohibited. The keywords

33、 “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” and in addition indicates t

34、hat 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 implement optional provi

35、sions (“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 formal languages; then figu

36、res; and then any other language forms. SMPTE ST 430-14:2015 Page 7 of 27 pages 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 standard

37、s 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 298:2009, Universal Labels for Unique Identification of Digital Data SMPTE ST 336:2007, Data Encodi

38、ng Protocol Using Key-Length-Value 1) SMPTE ST 377:2004, Television Material Exchange Format (MXF) File Format Specification 1) SMPTE ST 379:2004, Material Exchange Format (MXF) MXF Generic Container SMPTE ST 429-2:2013, D-Cinema Packaging DCP Operational Constraints SMPTE ST 429-6:2006, D-Cinema Pa

39、ckaging MXF Track File Essence Encryption SMPTE ST 429-14:2014, D-Cinema Packaging Aux Data Track File SMPTE ST 430-10:2010, D-Cinema Operations Auxiliary Content Synchronization Protocol AES3-2009, AES Standard for Digital Audio Engineering Serial Transmission Format for Two-Channel Linearly Repres

40、ented Digital Audio Data IETF RFC 2616, Hypertext Transfer Protocol HTTP/1.1 IETF RFC 2818, HTTP over TLS IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax IETF RFC 6597, RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data IETF RFC 223

41、4, Augmented BNF for Syntax Specifications: ABNF IETF RFC 4122, A Universally Unique Identifier (UUID) URN Namespace IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 1) Note: The reference to SMPTE ST 377:2004 (http:/dx.doi.org/10.5594/S9781614827689) and SMPTE ST 37

42、9:2004 (http:/dx.doi.org/10.5594/S9781614828068) are intentional. SMPTE ST 377-1:2011 and SMPTE ST 379-1:2009 or future versions are not appropriate for use with this document. SMPTE ST 430-14:2015 Page 8 of 27 pages 4 Terms and Definition 4.1 Timeline As illustrated in Figure 4, the Timeline is a s

43、equence of N contiguous Timeline Edit Units, resulting from the successive and uninterrupted playback of one or more Compositions in their entirety. Timeline Edit Units can have different duration to accommodate change of edit rates across Composition boundaries. Figure 4 Timeline The Timeline Edit

44、Units are indexed from 0 for the first Timeline Edit Unit to N-1 for the last Timeline Edit Unit. 4.2 Primary Picture The primary picture is the picture projected on the main screen of the auditorium, commonly the output of the Primary Picture Track File. 4.3 Primary Picture Track File The Primary P

45、icture Track File is the Track File referenced by the Composition Playlist MainPicture or MainStereoscopicPicture element associated with the Timeline Edit Unit. 4.4 Primary Sound Track File The Primary Sound Track File is the Track File referenced by the Composition Playlist MainSound element assoc

46、iated with the Timeline Edit Unit. 4.5 Server Source of the Data Items transmitted using the Transfer Protocol. 4.6 Emitter Source of the Synchronization Signal. 4.7 DCS Digital Cinema Server as defined in SMPTE ST 430-10. 4.8 ACS Auxiliary Content Synchronization as defined in SMPTE ST 430-10 1 2 0

47、 10 1 2 0 0 1 8 0 1 2 8 0 1 2 8 0 2E d i t U n i t I n d e x 1 8 0 0C h a n g e o f e d i t r a t eC P L # 1 R e e l # 1 C P L # 2 R e e l # 1 C P L # 2 R e e l # 2SMPTE ST 430-14:2015 Page 9 of 27 pages 5 Synchronization Signal 5.1 General Bits are numbered starting at 0 for the least significant b

48、it. Note: Bit structures are documented using the conventions used in AES3, with the least-significant bit positioned to the left. Hexadecimal constants are prefixed with “0x“ and written most-significant bit and byte first. EXAMPLE: The unsigned integer constant 0xAAF0 corresponds to the decimal in

49、teger 43,760. 5.2 Structure As illustrated in Figure 5, the Synchronization Signal shall consist of a sequence of 24-bit Samples, grouped into Packets separated by zero or more Fill Samples. Figure 5 Synchronization Signal Each Fill Sample shall be equal to 0x000000. Each Packet shall consist of the payload of Section 5.3 mapped to a sequence of Sample-Pairs, each consisting of a Lead Sample followed by a Tail Sample. As illustrated in Table 1, the lower 16 bits of the nth Lead Sample of a Packet shall be equal to the nth Word of the