1、SMPTE 357M-2002 SMPTE STANDARD for Television - Declarative Data Essence - Internet Protocol Multicast Encapsulation Table of contents 1 Scope and application 2 Normative references 3 Announcement protocol 4 Trigger protocol 5 Resource transfer: UHTTP Annex A Using enhanced television Annex B Exampl
2、e broadcast Annex C Glossary 1 Scope and application 1.1 Scope This standard defines the encapsulation of declarative data essence using internet protocol (IP) muiticast. This is done in a transport-independent manner and relies solely on standard IP multicast techniques. 1.2 Application This standa
3、rd defines the transmission of declarative content across terrestrial (over the air), cable, and satellite systems as well as over the Internet. In addi- tion, it will also bridge between networks - for example, data on an analog terrestrial broadcast must easily bridge to a digital cable system. Th
4、is design goal was achieved through the definition of a trans- port-independent content format and the use of IP. Since IP bindings already exist for each of these video systems, the advantages of this work may be useful. IP multicast is the mechanism for broadcast data delivery. Content creators sh
5、ould assume IP addresses may be changed downstream and, there- fore, should not use them in their content. The trans- port operator is responsible only for makhg sure that an IP address is valid on the physical network where they broadcast it (not for any rebroadcasting). When Page 1 of 8 pages poss
6、ible, content creators should use valid IP multi- cast addresses to minimize the chance of collisions. Some systems may have two-way Internet connec- tions. Capabilities in those systems are outside the scope of this standard and are described by the appropriate Internet standards. Transport operato
7、rs should use the standard IP trans- mission system for the appropriate medium (IETF, ATSC, DVB, etc.). It is assumed that when the user tunes to a television channel, the receiver automat- ically locates and delivers IP datagrams associated with the television broadcast. The mechanism for tuning vi
8、deo and connecting to the appropriate data stream is implementation and delivery standard specific and is not specified in this framework. 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of p
9、ublication, 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 edition of the standards indicated below. SMPTE 363M-2002, Television - Declarative Data Es
10、sence - Content Level 1 SMPTE 364M-2001, Television - Declarative Data Essence - Unidirectional Hypertext Trancport Protocol IETF RFC 768, User Datagram Protocol (UDP) IETF RFC 791, Internet Protocol - DARPA Internet Program Protocol Specification IETF RFC 1112, Host Extensionsfor IP Muiticasting Co
11、pyright OW by ME SOCIEPI OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hafisdadale Ave, White PiainS. NY 10607 (914) 761-1100 Approved January 3,2002 SMPTE 357M-2002 IETF RFC 2327, SDP: Session Description Protocol IETF RFC 2974, Session Announcement Protocol (SAP) ISO/IEC 11578:1gg6, Informatio
12、n Technology - Open Systems Interconnection - Remote Procedure Call (RPC), Annex A, Universal Unique Identifier (UUID) incorrect. In this case, the start time should be set to the original broadcast time and the stop time set to O. This is the standard for an unbounded session. Assumptions are then
13、made about the stop time (see IETF RFC 2327). Anew announcement with the same cid and different version for the same broadcast station replaces the Previous one. It is Preferred that a tool read the tape and generate announcements with cor- 3 Announcement protocol Announcements are used to announce
14、currently available programing to the receiver. The IP multicast addresses and ports for resource transfer and for triggers are announced using SDP announcements (IETF RFC 2327). The SDP header is preceded by an 8-byte SAP header (IETF RFC 2974). An- nouncements are sent on a well-known address (224
15、.0.1.113) and port (2670). This address and port have been registered with the IANA. v=O SDP version, required to be O. o=usemame sid version IN IP4 ipckress Owner and session identifier, defined as usual in SDP specifica- tion. Username is ”-”, network type is IN, address type is IP4. Sid identifie
16、s an announcement for a particular broadcast (it can be a permanent announcement for all programming on a broadcast channel or for a particular show). Version indicates the version of the message. These values allow receivers to match a message to a previous message and know whether it has changed.
17、Session ID and Version should be NTP values as recornmended in SDP. s=name Session name, required as in SDP specifi- . cation. i=, u= Optional, as in SDP specification. e=, p= E-mail address or telephone number (at least one required in SOP specification). b=CTnumber Optional in SDP specification, b
18、ut required here. Bandwidth in kilobytes per second as in the SDPspecification. Bandwidth of the broad- castdata can be used by receivers to choose among multiple versions of enhancement data accord- ing to the bandwidth the receiver can handle. t=starf stop As in SDP specification, gives start and
19、stop time in NTP format. With programs stored on tape, at times it will not be possible to insert new announcements, so start times on tape could be rect start and stop times, but it is not required. Content creators can choose to use only a station ID and not provide information about individual pr
20、ograms. a=UUID:UUID Optional. The UUID should uniquely identify the enhancement (for example, a different UUID for each program), and can be accessed using the trigger receiver object. In analog television and many types of digital television broadcast data are tied tightly to AN. Each virtual chann
21、el has its own private networkassociated with it. In othersystems, enhance- ments for many virtual channels can be carried on the same network. These systems can use the UUID to link a television broadcast with a particular enhance- ment. How that association is indicated is beyond the scope of this
22、 standard. One technique would be to place the UUID in electronic program guide informa- tion. Use ASCII hex to encode UUIDs. a=Slpe:tve Required. Indicates to the receiver that the announcement ref ers to an enhancement related to this specification. a=lang, a=sdplang Optional, as in SDP specificat
23、ion. a=tve-type: Optional. tve-type: specifies an extensible list of types that describe the nature of the enhancement. It is a session-level attribute and is not dependent on a=tve-type:phay. Optional. tve- type:primary specifies that this will be the primary enhancement stream associated with the
24、currently playing video program whenever this enhancements trigger stream is active. If tve-type:primary is not specified, the TVE stream is never the primary en- hancement stream associated with video. This, like all tve-type: attributes, is a session level attribute. This attribute can be used by
25、receivers to implement auto- matic loading of primary video enhancement streams. The actual display of and switching between enhance- ment streams are handled by the trigger streams. a=tve-size.-l(byes Required. tve-size: provides an estimate of the high watermark of cache storage in kilobytes that
26、will be required during the playing of the enhancement. This is necessary so that receivers can Page 2 of 8 pages SMPTE 357M-2002 adequately judge whether or not they can successfully play an enhancement from beginning to end. a=tve-leve/x Content level identifier, where x is 1 .O for this version o
27、f the framework (optional, default is 1 .O). a=tve-ends:seconds Optional, specifies an end time relative to the reception time of the SDPannouncement. Seconds is the number of seconds in the future that this announcement is valid. Seconds may change (count down) as an announced session progresses. T
28、his attribute, when present, overrides the default assump- tions for end times in unbounded announcements. m=data portvalue/2 tve-file/tve-trigger c=IN /P4 ipaddresdtt/ As in SDP specification. Com- pact form specifying two ports on the same address. When there are multiple alternative enhancement s
29、treams for the same video program, they must all be announced at the media level of the same SDP announcement. All enhancement streams announced in the same SDP announcement are considered to be mutually exclusive variants of the primary enhance- ment stream. The receiver can choose between them bas
30、ed on media level attributes. For example, the a=/angfield can be used at the media level to choose between language variants of the primary enhance- ment. Each media section for the tve-file media type begins the next enhancement definition. A longer form is available if the content creator or tran
31、sport operator wants to use different IP addresses and ports for the data stream and trigger stream: m=data portvalue tve-file c=/N IP4 ipaddresdttl Alternative form for specitying addresses and ports (for file protocol, as in SDP specification). m=data portvalue tve-trigger c=IN IP4 ipaddresdttl (f
32、or control protocol, as in SDP specification). Announcement example: v=o O = -2890844526 2890842807 IN IP4 tve.niceBroadcaS s = Day & Night & Day Again i = Avery long TV Soap Opera e = help niceB a = UUID:f81 d4fae-7dec-11 dO-a765-00aOc91 e6bf6 a = type:tve a = tve-level:l .O t = 2873397496 O a = tv
33、e-ends:30000 a = tve-type:primary m = data 52127/2 tve-filehe-trigger c = IN IP4 224.0.1.112/127 b = CTIOO a = tve-size: 1024 m = data 5212712 tve-fileltve-trigger c = IN IP4 224.0.0.1/127 b = CT 1024 a = tve-size:4096 4 Trigger protocol The trigger protocol carries a single trigger in a single UDP/
34、IP multicast packet. Triggers are real-time events broadcast inside IP multicast packets deliv- ered on the address and port defined in the SDP announcement for the enhanced television program (see announcements). The trigger protocol is thus very lightweight in order to provide quick synchroni- zat
35、ion. 5 Resource transfer: UHTTP A one-way IP multicast based resource transfer pro- tocol, the unidirectional hypertext transfer protocol (UHlTP), is defined in SMPTE 364M. UHlTP is a simple, robust, one-way resource transfer protocol that is designed to deliver efficiently resource data in a one-wa
36、y broadcast-only environment. This re- source transfer protocol is appropriate for IP multicast over television vertical blanking interval (IPVBI), in IP multicast carried in MPEG-2, or in other unidirectional transport systems. Web pages and their related resources (such as images and scripts) are
37、broadcast over UDPAP multicast in the related television signal. An announcement broad- cast by the television station tells the receiver which IP multicast address and port to listen to for the data. The only data broadcast to this address and port are resources intended for display as web content.
38、 While HlTP headers preceding resource content are optional in the UHlTP protocol, they are required when the protocol is used for DDE. Compliant receivers must support gzip content encodings as specified by the content-encoding HTTP header field. Page 3 of 8 pages CMPTE 357M-2002 Version (3 bits) 1
39、 SAP version Message type (3 bits) O Session description announcement packet Encrypted (1 bit) O Not encrypted Compressed (1 bit) O Not compressed Annex A (informative) Using enhanced television Television enhancements are comprised of three related data sources: announcements (delivered via UDP usi
40、ng SAP/SDP), content (delivered via UHTTP), and triggers (de- livered via the trigger protocol over UDP). Announcements are broadcast on a single well-known multicast address and have a time period for which they are valid. This time period is expressed via the Y= and a=tve-ends:“ lines within the S
41、DP record. Announcements also indicate the multicast address and port number that the client can listen in on to receive the content and triggers. The announcement also contains information that the client optionally can use to help decide whether to automatically start receiving triggers and conten
42、t information. This may include a=tve-type, lang=, and keywds= attributes that pro- vide additional infomation to the client about the announced enhancements. For example, announcements with an optional a=tve-fype:primary attribute may be used by the client to implement an auto-play feature. Multipl
43、e a=tve-type attributes may appear in a given announcement and are not mutually exclusive. Annex B (informative) Example broadcast The following is a simple example of a television enhance- ment, delivered via transport type B (multicast IP). The example consists of three parts: the announcement (an
44、- nounced via SDP/SAP), the content (delivered via UHTTP), and the triggers (delivered in UDP packets). A complete SAP header would be 8 bytes: 0x20, 0x00, 0x34, 0x64, Oxdl, OxfO, Oxc3, 0x06. The remaining bytes in the announcement packet would contain the following text payload: The experience cons
45、ists of a screen with 60% sized embed- ded live television object, with some text below it. During the show, a trigger may arrive that will cause an image of the word MURDER to appear below the text. If the user chooses to click on the television object, they will be returned to full- screen video,
46、and away from the enhanced experience. B.l Announcement The following announcement packet is sent via UDP to the multicast IP address: 224.0.1.1 13, port: 2670. The announcement consists of an 8-byte SAP header fol- lowed by an SDP text payload. The values for the SAP header fields for the announcem
47、ent shall be as given in table B.l. v=o 0=-2890844526 2890842807 IN IP4 tve.niceB s=Day & Night & Day Again i=A very long TV Soap Opera e=heIpniceB a=UUID:f81 d4fae-7dec-11 dO-a765-00aOc91 e6bf6 a=type:tve a=tve-1evel:l .O a=tve-ends:l800 a=tve-type:primary m=data 52127/2 tve-fileltve-trigger a=tve-
48、size: 1024 These fields are indicated in table 8.2. t=2873397496 O c=IN IP4 224.0.1.112/127 b=CT:40 Table B.l - SAP header fields values I Field name (size) I Value I DescriDtion I I Authentication length (1 byte) I ox00 I No authentication I I Message ID hash (2 bytes) I 0x3464 I Hash of payload te
49、xt I Originating source address (4 bytes) I 209.240.195.6 I IP address of originating host Page 4 of 8 pages CMPTE 3-M-2002 v= o o=-2890844526 2890842807 IN IP4 tve.niceB s=Day & Night & Day Again i=n very long TV Soap Opera e=help O niceB a=UUID:f81 d4fae-7dec-11 dO-a765-00aOc91 e6bf6 a=type:tve a=tve-1evel:l .O a=tve-ends:l800 a=tve-type:primary t=2873397496 O m=data 52127/2 tve-file/tve-trigger SDP version zero Originating host information Session name Session description Contact information about th
