13.1 Advanced Television Enhancement Forum (ATVEF)
| The ATVEF has produced a standard set of HTML extensions and facilitates the synchronization of data broadcasts with video feeds [ATVEF]. ATVEF has been adopted by OpenCable, as well as some key software providers such as Microsoft and Liberate. A few content providers are broadcasting ATVEF content today. WebTV users may be familiar with interactive Jeopardy, that allows viewers to play along with the popular game show. Informational broadcasts such as The Weather Channel, broadcast ATVEF content that enables viewers to go interactive and access detailed weather maps and local forecasts. The ATVEF specification was designed by a consortium of broadcast and cable networks, consumer electronics companies, television transport operators and technology companies to define a common, worldwide specification for enhanced television programming [ATVEF]. The specification consists of three parts :
ATVEF delivers enhanced TV programming over analog and digital video systems using terrestrial, cable, satellite, and Internet networks. For the delivery of data enhancements, it relies on existing Internet technologies. The specification can be used in both one-way broadcast and two-way video systems, and is designed to be compatible with all international standards for both analog and digital video systems. A key strategy for the ATVEF standardization effort was the integration of existing technologies, as opposed to development of new immature technologies. The content produces in the group determined that existing Internet standards, with only minimal extensions for television integration, provide a sufficiently rich set of capabilities for building enhanced TV content. The ATVEF specification references full existing specifications for HTML, ECMAScript, DOM, CSS, and media types as the basis of the content specification. Another key design goal was the provision of a single solution for a wide variety of networks. ATVEF defines a transport-independent content format and includes the bindings to IP-based and NTSC-based transports. In general, ATVEF can work with, or leverage, any video format for which IP bindings exist or can be easily defined. ATVEF is capable of running on both analog and digital video systems as well as networks with no video at all. The specification also supports transmission across terrestrial broadcast, cable, and satellite systems as well as over the Internet. In addition, it provides a bridge between networks of different types. As an example, content delivered through an analog terrestrial broadcast can be easily transcoded to enable its delivery with a digital cable system. ATVEF defined a simplified content food chain comprising content producer, transport operator, and receiver manufacturer. The content producer originates the content components of the enhancement including graphics, layout, interaction and triggers. The transport operator runs a video delivery infrastructure (terrestrial, cable, satellite or other) that includes a transport for ATVEF data. The receiver manufacturer provides the hardware and software implementation (television, set-top box, or personal computer) that decodes and plays ATVEF content. An organization may play more than one of these roles. 13.1.1 Content SpecificationsThe ATVEF content specification reassures content producers that a minimum set of capabilities are available for the delivery and rendering of the content they produce. There are no constraints on the types of data and formats that an ATVEF transport may carry. This includes HTML, VRML, Java, other future formats (e.g., XHTML) and private data files. When the content author knows the special capabilities and limitations of the target receiver, data can be sent over ATVEF transport that is not compliant with the specification, including Dynamic HTML (DHTML), Java, or even private data files. 13.1.1.1 Content FormatsThe foundation for ATVEF content is existing Internet standards such as IP, HTTP and HTML. All receivers support HTML 4.0, CSS 1.0, ECMA Script, DOM0 (i.e., ECMA+DOM0 = JavaScript 1.1). Receivers are required to provide 1KB for session cookies that may not persist when the receiver is turned off. Table 13.1 presents the base profile of MIME types that are supported in each receiving implementation. Table 13.1. Minimum Support Required from ATVEF Receivers
13.1.1.2 ATVEF TriggersATVEF Triggers are events delivered for controlling the enhancement of TV programs. Typically, triggers initiate or control active enhancements using DHTML-style scripting. They can be delivered using any transport for which ATVEF binding exists (e.g., IP, NTSC, Captioning). Triggers always include a URL, and may optionally also include a human-readable name , an expiration date, and a script, to be executed by the receiver on reception . Receiver implementers are free to decide how to turn on enhancements and how to enable the user to choose among enhancements. As an example, receivers may use trigger arrival as a signal to notify users of availability of interactive enhancement. Triggers that include a name attribute may be used to initiate an enhancement either automatically, or with user confirmation. The initial top-level page for that enhancement is indicated by the URL in that trigger. Triggers that do not include a name attribute are not intended to initiate an enhancement, but should only be processed as events that affect enhancements that are currently active through the script attribute. For example, if the URL of a trigger matches the URL of the current top-level page, and the expiration specified by the trigger has not been reached, the script is executed. The content of triggers is text based. It begins with ASCII '<' (Receivers should ignore triggers that do not begin with '<'). The syntax of triggers content follows the basic format of the EIA-746A standard (7-bit ASCII, where the high-order bit of the first byte is "0"). The MIME content type is application/tve-trigger . The general format for triggers is as follows: <url> [attr1: val1][attr2:val2]...[attrn:valn][checksum]
The following are examples of valid trigger strings: [View full width]
13.1.1.3 The Local Identifier URI Scheme ( lid: )Content delivered by a one-way (push) broadcast is not necessarily available on-demand, as it is when delivered by a (pull) request response mechanism such as using HTTP or FTP. To enable locating and extracting resources from the broadcast transport, it is necessary to have a name space local to the transport. To support cross-references within the content (for use in hyper-links or to embed one piece of content in another), these local names are location-independent. The lid: URI scheme enables content authors to assign unique identifiers to each resource relative to a given namespace. Thus the author can establish a new namespace for a set of content and then use simple, human-readable names for all resources within that space. In ATVEF IP transports, the lid: scheme is used by the Content-Location: field in the Unidirectional HTTP (UHTTP) resource transfer header to identify resources that should be stored locally by a broadcast capable receiver platform and are not accessible via the Internet. The syntax of the lid: URL is as follows:
The {namespace-id} specifies a unique identifier (e.g., UUID or a domain name) to use as the namespace for this content. The {resource-path} names a specific resource within the namespace, and follows the generic relative URL syntax. As with all URI schemes that support the generic relative URI syntax, this path component can be used alone as a relative URI, where the namespace is implied by a base URI specified for the content through other means. Although all compliant implementations of enhanced TV receivers support absolute URIs within the UHTTP header and broadcast triggers, some implementations may not correctly process absolute URIs using the lid: scheme within HTML content. Content producers should use only relative URIs. The full lid: URI is only needed by triggers initiating an enhancement and loading the main HTML page; that page as well as all other pages should use relative URIs. Example valid lid URIs are as follows: lid://identifier123@babel.com/photo.jpg lid://xyz.com/myshow/episode100/george.html lid://3d3dd3f154c2abd3ddc554c312abc53f/logos/star.gif The first example uses a RFC 822 message-id style unique ID, the second one uses a domain name as a unique identifier, and the third uses a text encoding of a UUID. Each is a valid mechanism for describing a lid: namespace. 13.1.1.4 Integrating TV with Web-pagesThe tv: URI, Uniform Resource Identifiers for Television Broadcasts RFC 2838, is used to reference a broadcast television channel. The tv: URI may be used in any location where a URI may reference an image. The primary video broadcast in the referenced channel is displayed in the area allocated for that image. Examples of elements that can use the tv: URI include the <object/> , <img/> , <body/> , <frameset/> , <a/> , <div/> , and <table/> elements.
13.1.2 ATVEF Transport SpecificationsAll forms of ATVEF transport involve data delivery and triggers. The capability of networks for one-way or two-way communication drives the definition of two models of transport. Transport A is designated data broadcasts when a return channel is available. Transport B is designed for situations when the return channel is not available. 13.1.2.1 Transport Type A: Return-path DataSome existing broadcast data services provide a mechanism for trigger delivery, but not resource delivery, due to limited bandwidth. Content creators may encode broadcast data triggers using these. Broadcast data streams only contain broadcast data triggers so there is no announcement or broadcast content delivery mechanism. Because there are no announcements, the broadcast data service stream is considered to be implicitly announced as a permanent session. In addition to the other attributes used in triggers, ATVEF transport type A triggers contain the attribute tve: indicating to the receiver that the content of the trigger conforms to a specific ATVEF Level, e.g., [tve:1.0] . The tve: attribute can be abbreviated as the single letter "v". The version number can be abbreviated to a single digit when the version ends in ".0" (e.g. [v:1] is the same as [tve:1.0] ). The tve: attribute is equivalent to the use of type:tve and tve-level: in SAP/SDP announcements in the transport type B IP multicast binding. This attribute is ignored if present in a trigger in transport B because these values are set in transport type B in the announcement. If the tve: attribute is not present in a transport type A trigger, the content described in the trigger is not considered to be ATVEF content. It is assumed that when the user tunes to a TV channel, the receiver locates and delivers broadcast data triggers associated with the TV broadcast. Tuning and decoding broadcast data triggers is implementation, and delivery standard specific and is specified in the appropriate ATVEF binding. A mechanism is defined for encoding broadcast data triggers for each standard delivery ATVEF content. For example in the NTSC binding, the broadcast data trigger syntax is encoded on the Text2 (T2) channel of line 21 using the EIA-746A system. Because there is no content delivery system, broadcast data triggers usually require two-way Internet connections to fetch content over HTTP. Television transport operators and content creators need to plan to handle the scalability issues associated with large numbers of HTTP requests responding at roughly the same time to broadcast triggers. 13.1.2.2 Transport Type B: Broadcast DataTransport type B is for true broadcast of both the resource data and triggers. As such, transport type B can run on TV broadcast networks without Internet connections, unlike transport type A. Transport type B uses announcements to offer one or more enhancements of a TV channel. An announcement specifies the location of both the files that provide content and the trigger stream for an enhancement. In addition to locating the files and trigger streams, announcements can provide the language, start and stop times, bandwidth, peak storage size needed for incoming resources, ATVEF content level the resources represent, an optional UUID that identifies the content, an optional string that identifies the broadcast channel for systems that send ATVEF content separately from the audio/video TV broadcast. Multiple enhancements can be offered as choices that differ on characteristics like language or required cache size or bandwidth. The receiver can receive data relevant to its capabilities. Transport type B also requires a protocol that provides for delivery of resources. In one-way broadcast systems, this is a one-way resource transfer protocol that allows for broadcast delivery of resources. The resource delivered includes HTTP headers to package the file (regardless of the transport method). All resources delivered using resource transfer are named using URIs. These resources are then stored locally, and retrieved from this local storage when referenced using this same URI. All receivers supports local storage and retrieval of content using the lid: URI scheme and the familiar http: URI scheme. When lid: is used, the resources are delivered only through broadcast and are not available on demand through the Internet. When http: is used, the resources that are delivered through broadcast also exist on the World Wide Web and can be requested from the appropriate server using standard HTTP. Sending http: resources using resource transfer effectively pre-loads the local cache, thus avoiding large numbers of simultaneous hits on Web servers when those same resources are requested by many receivers. Furthermore, this mechanism allows receivers to view the same content that appears on the Web even when no Internet connection is available. Content authors can freely mix resources that use either the lid: or http: schemes in the same enhanced broadcast. Because the underlying resource transfer protocol is not limited to carrying resources named by any particular URI scheme, some receivers store and retrieve content which is named using other URL schemes, such as ftp: , as well as the required lid: and http: . The "ATVEF Reference Binding for IP Multicast" describes three protocols based on IP multicast transmission for each of the three data streams: (a) announcements; (b) triggers; and (c) one-way resource transfer. 13.1.2.3 Simultaneous Support of Transports A and BA single video program may contain both transport type B (e.g., IP) and transport type A (e.g., broadcast data triggers) simultaneously . This is advantageous to target both IP-based receivers and receivers that can only receive broadcast data triggers. Receivers may choose to support only IP based trigger streams and ignore broadcast data triggers, or receivers may support broadcast data triggers in the absence of IP based triggers, or receivers may support broadcast data triggers and IP based triggers simultaneously. When a broadcast data trigger is encountered , its URI is compared to the URI of the current page. If the URIs match and the trigger contains a script, the script should be executed. If the URIs match but there is no script, the trigger is considered a re-transmission of the current page and should be ignored. If the URIs do not match and the trigger contains a name, the trigger is considered a new enhancement and may be offered to the viewer. If the URIs do not match and there is no name, the trigger should be ignored. 13.1.3 ATVEF BindingsAn ATVEF binding is a definition of how ATVEF runs on a given network. The ATVEF binding provides the glue between the network spec and the ATVEF spec, when the network specification doesn't contain all the necessary information. The measure of a sufficient ATVEF binding is that all the data needed to build a compliant, interoperable receiver for a given network should be contained in the ATVEF spec, the network spec, and the ATVEF network binding, if needed. The binding may support either or both transport types A and B. Having one standard ATVEF binding for each network is necessary so that receivers and broadcast tools can be developed independently. ATVEF defines the binding to IP as the reference binding. Because IP is available to run over virtually any kind of network in existence. That means that one approach to building an ATVEF binding for a particular network is to simply define how IP is run on that network associated with a particular video program. The IP binding can also be used as a model for a complete, compliant, efficient ATVEF binding. The ATVEF specification also includes an example of a binding to a specific network standard-the ATVEF binding to NTSC. This binding can be used as a model for how to build an ATVEF binding to a specific video standard. The example NTSC binding defines transport type A using an NTSC-specific method and defines transport type B using the IP reference binding. With ATVEF, the primary (reference) binding is IP-multicast. Content authors should assume IP addresses may be changed downstream, and therefore should not use them in their content. The transport operator is only responsible for making sure that an IP address is valid on the physical network where they broadcast it (not for any rebroadcasting). When possible, content authors should use valid IP multicast addresses to minimize the chance of collisions. Transport operators should use the standard IP transmission system for the appropriate medium (IETF, ATSC, DVB, etc.). It is assumed that when the user tunes to a TV channel, the receiver automatically locates and delivers IP datagrams associated with the TV broadcast. The mechanism for tuning video and connecting to the appropriate data stream is implementation and delivery standard specific and is not specified in this framework.
13.1.3.1 ATVEF Binding to NTSCTo integrate with NTSC, ATVEF data is broadcast within the VBI of individual video fields. Transport A: VBI Line 21ATVEF triggers are transmitted on VBI Line 21 of the NTSC signal using the T-2 service as specified in EIA-608 which describes how to send URLs and related information on VBI line 21 without interfering with other data (e.g., closed captions) also sent on that line. ATVEF trigger length should be kept as short as possible and should be limited to 25% of the total field bandwidth, even if more bandwidth is available. Transport B: IP over VBIIP datagrams should be sent according to the specification drafted by the IP over VBI working group of the IETF. NABTS (rather than WST) byte encoding should be used. IP streams should be sent on the packet addresses 0x4b0 through 0x4bf. Further, it is recommended that a 1 MByte buffer be used in the receiver. 13.1.3.2 Disadvantages of ATVEFSome of the disadvantages of ATVEF are that triggers are synchronous only (i.e., it is not possible to specify presentation times) and there is no buffer model (i.e., delivery contract) for triggers or content. Further, television transport operators and content producers need to plan to handle the scalability issues associated with large numbers of HTTP requests responding at roughly the same time to broadcast triggers. These issues are addressed by DVB-MHP through the use of MPEG-based transports and buffer models. |
frame1"] <http://www.newmfr.com>[name:New][C015] 
EAN: 2147483647
Pages: 170