SMPTE ST 430-10-2010 D-Cinema Operations Auxiliary Content Synchronization Protocol《数字电影运营 辅助内容同步协议》.pdf

《SMPTE ST 430-10-2010 D-Cinema Operations Auxiliary Content Synchronization Protocol《数字电影运营 辅助内容同步协议》.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 430-10-2010 D-Cinema Operations Auxiliary Content Synchronization Protocol《数字电影运营 辅助内容同步协议》.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

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

2、erview (Informative) . 4 5.1 Composition Playlist Resources 4 5.2 Resource Loading 5 5.3 Protocol Description . 5 6 Communications Protocol 5 6.1 Control Protocol . 5 6.2 General Message Elements . 6 6.3 General Message Requirements . 6 6.4 Status Responses 6 7 General Purpose Messages. 7 7.1 BadReq

3、uest Response 7 7.2 Message Summary 8 Annex A Auxiliary Content Synchronization Protocol Variable Length Universal Label (UL) Key (Normative) . 16 Annex B Protocol Usage (Informative) . 18 B.1 Example Transaction . 18 Page 1 of 18 pages SMPTE ST 430-10:2010 SMPTE STANDARD D-Cinema Operations Auxilia

4、ry Content Synchronization Protocol SMPTE ST 430-10:2010 Page 2 of 18 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

5、 over 80 countries on six continents. SMPTEs Engineering 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

6、 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. SMPTE ST 430-10 was prepared by Technology Committee 21DC. Intellectual Property At the time of publica

7、tion no notice had been received by SMPTE claiming patent rights essential to the implementation of this Standard. 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

8、 all such patent rights. SMPTE ST 430-10:2010 Page 3 of 18 pages 1 Scope This document defines a protocol for synchronizing auxiliary resources in a composition playlist to the playback timeline. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensab

9、le 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 editorially without affecting interoperability. Informative text does not contain any conforma

10、nce 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 “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the

11、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 excluding others; or that a certain course of action is preferred but not necessarily required; or

12、 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 document. The keyword “reserved” indicates a provision that is not defined at this time, shall no

13、t 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. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implement

14、ed, all recommended provisions (“should“) as described. A conformant implementation need not 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:

15、 Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. 3 Normative References Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 336:2007)

16、although, during a transitional phase, the document as published (printed or PDF) may bear an older designation (such as SMPTE 336M-2007). Documents with the same root number (e.g. 336) and publication year (e.g. 2007) are functionally identical. The following standards contain provisions which, thr

17、ough 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 standard are encouraged to investigate the possibility of applying the most recent editio

18、n of the standards indicated below. 336 SMPTE ST 336:2007, Data Encoding Protocol Using Key-Length-Value IANA Internet Assigned Numbers Authority. See www.iana.org/assignments/port-numbers SMPTE ST 430-10:2010 Page 4 of 18 pages CPL SMPTE ST 429-7:2006, D-Cinema Packaging Composition Playlist RPL SM

19、PTE ST 430-11:2010, D-Cinema Operations Auxiliary Resource Presentation List 4 Glossary The following paragraphs define the acronyms used in this document. ACS: Auxiliary Content Server BER: Basic Encoding Rules CSP: Auxiliary Content Synchronization Protocol (this document) DCS: Digital Cinema Serv

20、er HTTP: Hypertext Transfer Protocol KLV: Key Length Value RRP: Request-Response Pair Show: An ordered sequence of compositions RPL: Auxiliary Resource Presentation List TCP: Transmission Control Protocol Uint8: 8-bit unsigned integer Uint32: 32-bit unsigned integer Uint64: 64-bit unsigned integer I

21、nt64: 64-bit signed integer UUID: Universally Unique Identifier URI: Uniform Resource Identifier URL: Uniform Resource Locator 5 Overview (Informative) This document defines a protocol for synchronizing auxiliary resources in an Auxiliary Resource Presentation List (RPL) to the playback timeline. Th

22、is protocol is intended for use between a Digital Cinema Server (DCS) and one or more Auxiliary Content Servers (ACS). Examples of such servers are: Caption servers Special effects servers (e.g. lightning strobe, chair rumble) Secondary display servers 5.1 Composition Playlist Resources The Composit

23、ion Playlist defines the resources to be presented during playout. At a minimum, these resources will consist of video and/or audio but may also contain subtitles, several types of captions, and other possible tracks. While each resource track is referred to by a single ID, the actual resource may c

24、onsist of many files; e.g. font file, XML files, image files, etc. SMPTE ST 430-10:2010 Page 5 of 18 pages 5.2 Resource Loading While the audio and video tracks in the Composition Playlist can be streamed in real time on a frame-by-frame basis, auxiliary content resources may have files that need to

25、 be preloaded (e.g. font files). Auxiliary content resources may be preloaded into the ACS to ensure that all concurrent files are ready to be used. 5.3 Protocol Description Prior to playout, the DCS will create a new Auxiliary Resource Presentation list (RPL) file, whose location will be sent to th

26、e ACS. The ACS will use HTTP to connect back to the DCS to acquire the RPL and the first set of resources that needs to be cached. After the ACS has finished caching resources, it will indicate its status as OK. Once playback starts, the DCS will enable resource output and send timeline updates to t

27、he ACS which will render the resource associated with the current timeline value. 6 Communications Protocol 6.1 Control Protocol The Control Protocol is a TCP-based protocol used to instruct the ACS which resources should be played with the timeline and when to play the referenced resources. The pro

28、tocol operates in a master/slave fashion with the DCS sending requests and the ACS sending synchronous responses. As outlined in Annex B, the connection is first initiated by the ACS. The SMPTE standardized messages in this protocol shall use well-known port 4170 which has been reserved for D-Cinema

29、 Auxiliary Content Synchronization Protocol RRPs by the Internet Assigned Numbers Authority (see IANA). 6.1.1 Connection Establishment The DCS shall listen for a connection on TCP port 4170. On connection initiation, the DCS must send the Announce request (See 7.2.1) to the ACS. On successful receip

30、t of the Announce response, the DCS may send subsequent requests depending on whether resources need to be presented for the next playout. The DCS may send no future messages past the Announce request to the ACS if the next show or composition does not require auxiliary resources. The DCS shall send

31、 the Announce message regardless of whether communications to the ACS is necessary for the next playout. 6.1.2 Message Structure: Key Length Value (KLV) Request and Response messages shall be Key Length Value (KLV) encoded using Fixed Length Pack encoding according to SMPTE ST 336 336. The Fixed Len

32、gth Universal Label (UL) Key is given in Annex A of this document. As a Fixed Length Pack, each individual item in the Value field comprises only an item value. The KLV Length field shall be a long-form BER value encoded with a fixed length of 4 bytes total. Example: For a KLV packet having a Value

33、field that is 12 bytes in length, the Length field would be encoded as the following 4 bytes, 0x83 0x00 0x00 0x0C (hexadecimal). Each Request-Response Pair (RRP) represents two message types and thus KLV UL “value” registration is required twice for each defined RRP (see Annex A ). SMPTE ST 430-10:2

34、010 Page 6 of 18 pages 6.2 General Message Elements For each message type, the following shall apply: The message type is denoted within the opening KLV “Key” field (16 bytes). “Length” is a BER-encoded four byte field which describes the length of the message in bytes. “Request_ID” shall be an appl

35、ication level tag for the Request, which shall be echoed in the corresponding Response. A non-zero Request_ID value shall be set by the DCS, which should select unique values (e.g. a sequencing counter) for each connection it manages. (Request_ID generation means is left to implementers and is out o

36、f the scope of this specification.) Multi-byte integer values shall be sent as big-endian data; i.e., the most significant byte is transmitted first. 6.3 General Message Requirements RRP transactions shall be synchronous (i.e., each pairing shall be opened and closed before a new RRP is opened betwe

37、en the same two entities). To avoid hang-ups, ACS implementations shall have a maximum round-trip Request-to-Response latency of 2 seconds. Latency shall be measured from the end of the “Request” message receipt to the start of the “Response” message transmission. If the ACS is too busy to accept or

38、 process a request, it shall send the corresponding response with the General Status Response Key of the Status Response set to ACS Busy. Should the ACS fail to respond (at all) after the 2 second time limit, the DCS may consider this a communications failure condition and may close the TCP connecti

39、on. 6.4 Status Responses Each response message shall contain a general status response value. The Status Response element is represented by the following structure: 6.4.1 General Status Response Key The General Status Response element identifies the general response for the response message. Possibl

40、e response values are as follows: Element Meaning UINT8 Value RRP successful Request successfully processed 0 RRP failed ACS unable to process Request 1 RRP Invalid Invalid parameter or Request structure 2 ACS Busy ACS too busy to process Request 3 Lease Timeout Lease not valid for last transaction

41、4 Playout ID Mismatch RPL and CSP Playout ID mismatch 5 General Error General Error response 6 Recoverable Error Recoverable Error 7 RPL Error Error parsing RPL 8 Resource Error Error parsing resource file 9 Processing ACS busy getting or interpreting resources 10 Reserved Reserved Response Elements

42、 11-255 Item Name Type Len Meaning General Status Response Key Uint8 1 General Status Response Response Text Length BER Length 4 Response Text Length Response Text Value Text Var Response Text Value SMPTE ST 430-10:2010 Page 7 of 18 pages Note: The Recoverable Error response can be returned by the A

43、CS to indicate a non-critical error that occurred during operation. This error can be ignored by the DCS but can also be used for logging purposes. 6.4.2 Response Text Length The Response Text Length field defines the length of the Response Text Value. If no Response Text Value is provided, the Resp

44、onse Text Length shall be set to the BER-encoded value of 0. 6.4.3 Response Text Value The Response Text Value field is a human-readable text value providing details about the associated General Status Response. The Response Text Value field shall be encoded using UTF-8 character encoding. If no Tex

45、t Value is provided, this portion of the response is not sent. 7 General Purpose Messages This section defines the general messages used in the protocol. 7.1 Bad Request Response Each RRP Response message contains a general “Status Response” element; however instances may arise where the ACS does no

46、t understand the incident Request that was received. In such case the appropriate Response would be unknown. The Bad Request Response shall be used when the ACS cannot otherwise respond with a Response appropriate to the incident Request. A complete copy of the Request message as received by the ACS

47、 is carried in this message. Bad Request Response Item Name Type Len UL Meaning Bad Request Response UL Name Pack Key 16 Identifies the Bad Request Response Length BER Length 4 n/a Pack length Request Copy Length BER Length 4 n/a Request Copy Length Request Copy Text Var Copy of Request Status Respo

48、nse KLV Var Status Response The Request Copy is a complete copy of the Request message that was not understood. SMPTE ST 430-10:2010 Page 8 of 18 pages 7.2 Message Summary Table 1 Message Summary Message Description Announce Initial announcement Get New Lease Establish a new connection lease Get Sta

49、tus Acquire high-level status of the ACS Set RPL Location Specify the HTTP URL for the resource map file Set Output Mode Instruct ACS to enable or disable resource output Update Timeline Update the current edit unit being displayed Terminate Lease Terminate the connection lease Get Log Event List Acquire the list of Log Events for a time range Get Log Event Acquire a Log Event 7.2.1 Announce After the ACS initiated the connection wi