1、EG 39-2003 SMPTE ENGINEERING GUIDELINE Overview of Declarative Data Essence Page 1 of 23 pages Table of contents 1 Scope 2 Introduction 3 Authorizing guidelines 4 Receiver behavior 5 Distribution issues 6 Ad insertion scenario details 7 Examples 8 Acronyms Annex A Javascript: URI scheme Annex B Bibl
2、iography 1 Scope This guideline provides an overview of the declarative data essence standards, describes how the various documents and technical components are related, and provides informative material useful to the users of these standards. 2 Introduction The initial group of standards were devel
3、oped in SMPTE based on the Advanced Television Enhancement Forum (ATVEF) specification ATVEF. These are collectively known as declarative data essence (DDE) derived from the terminology developed in the joint SMPTUEBU work found in SMPTE-EBU. This was further labeled as content level 1 after the ATV
4、EF specification for 1 .O, and in anticipation of both lower and higher content levels. Hence, the shorthand, DDEA1. The ATVEF specification was broken into six separate SMPTE documents that cover the original ATVEF specification. These specifications are: SMPTE 343M-2002, Television - Declarative D
5、ata Essence - Local Identifier (lid:) URI Scheme SMPTE 357M-2002, Television - Declarative Data Essence - IP Multicast Encapsulation SMPTE 361 M-2002, Television - NTSC IP and Trigger Binding to VBI SMPTE 363M-2002, Television - Declarative Data Essence - Content Level 1 SMPTE 364M-2001, Television
6、- Declarative Data Essence - Unidirectional Hypertext Transport Protocol Copyright O 2003 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdaie Ave., Whte Plains, NY 10607 (914)761-1100 Approved January 8,2003 EG 39-2003 SMPTE 366M-2002, Television - Document Object Model Level
7、O (DOM-O) and Related Object Environment The relationship of all six of these documents can be found in figure 1. Finally, it is worth noting that there is ongoing work (not covered in this guideline) on wrappers for this content for carriage in SMPTE KLV; and there is very early work on a content l
8、evel 2. DDE- 1 Wrappers however, there are two default fonts with specific font name sizes required to be supported. Authors are encouraged to make use of these fonts for better display control. The font sizes should be specified by their font name sizes. 3.3 ECMAScript Authors should avoid using ev
9、al() that results in dynamically generated HTML. Doing this makes transcoding of the content computationally impossible, and thus may affect the quality in future generation enhancement systems. 3.4 DOM-O Authors should avoid using document.write() with arguments other than constants. Doing this mak
10、es transcoding of the content computationally impossible, and thus may affect the quality in future generation systems. Page 3 of 23 pages EG 39-2003 3.5 URI schemes DDE-1 supports the URI schemes tv: pv, lid: LID, javascript: DDE-11 and http: HTTP. Only http: may be used for DDE-1 content that must
11、 be fetched from the Internet, which is always the case on Transport-A-only systems. The lid: scheme may not be used for Transport-A-only systems, because lid: implies that the content is broadcast as DDE-1 and cached locally, which is not the case with Transport A. On Transport-B systems, both lid:
12、 and http: schemes may be used as follows: either lid: or http: can be used for DDE-1 content that is broadcast and cached locally; only the http: scheme should be used for content that is not broadcast and not available locally, because the lid: scheme only works for locally cached content. Authors
13、 are specifically cautioned against using the common schemes, ftp:, https:, and shttp:. NOTE - The javascript: URI scheme is supported with certain limitations (see annex A for details). 3.6 UUID UUIDs would normally be generated automatically by the authoring tool through a call to the operating sy
14、stem to obtain one. UUIDs are often also called guids, and are available in some form on all popular operating systems. UUIDs are constructed in part from the MAC address of the network adapter being used in the computer doing the authoring. In the rare occurrence that a UUID needs to be generated f
15、rom a device without a network interface, then care must be taken to use an unused MAC address. This can be done by setting the most significant bit of the MAC address field (MAC address assignments use this to signal multicast destinations and would never be used for a real address). Alternatively,
16、 a statistically unique value can be generated through the hash of the fieid(s) as described further in RFC 2518, section 6.4.1 WEBDAV. 4 Receiver behavior This clause provides information which should be considered when implementing a decoder that decodes the DDE-1 content. Since DDE-1 content is a
17、n authoring standard and not a decoder standard, this may be helpful to manufacturers of any decoding equipment, including consumer electronics receivers. The term receiver here is generally meant to refer to any type of decoder. 4.1 Receiver model Figure 2 shows the receiver block diagram. Page 4 o
18、f 23 pages EG 39-2003 Video Video Decoder Interpretor w H Datacache Internet Data b Decoder Transport B Data Audio Mixer Audio Audio Figure 2 - Receiver block diagram 4.2 Enhancement characterization An enhancement is defined as content added to a video/audio service. An enhancement can further be d
19、escribed by its behavioral characteristics as specified in DDE-11. From this point of view, an enhancement is a sequence of topmost HTML documents whose content is specified in HTML. The first HTML document of an enhancement, the initiai topmost document, is always instantiated by means of a trigger
20、. Subsequent topmost documents within an enhancement are instantiated as a recuit of a navigation from the current document initiated either by a trigger or a viewer selection (see figure 3). 7 /navigaT viewedtrigger Doc 1 -b DOC 2 -+ . b Docn-1 ,-b Docn (Initial) Figure 3 - DDE-1 enhancement Page 5
21、 of 23 pages EG 39-2003 4.3 State model _- I 8 / 8 enhancement enhancements next document Figure 4 - Diagram for enhancement behavior Figure 4 shows the state diagram for enhancement behavior. Table 1 describes the basic types of triggers. The enhancement state model is described from the point of v
22、iew of the state transition arcs in figure 4. Each state transition can result from either a new enhancement trigger or a trigger for the current enhancement. Page 6 of 23 pages EG 39-2003 Table 1 - Basic trigger types En hancement NO I New 1 en hancement trigger Trigger for current enhancement YES
23、Trigger Description? Trigger with ?name? attribute, and URL DIFFERENT from the last topmost document of immediately preceding enhancement Trigger with ?name? attribute, and URL DIFFERENT from current enhancement?s current topmost documen? Trigger with URL EQUAL the URL of the current enhancement?s c
24、urrent topmost documen? NOTES When determining whether two URLs are DIFFERENT or EQUAL, characters in the URLc including and following the first ? or # are ignored in the comparison. May result in implementation specific behavior. 1 4.3.1 New enhancement triggers As shown in table 1, a new enhanceme
25、nt trigger is a trigger with a name attribute, and with either: a URL different from the last topmost document of the immediately preceding enhancement if no enhancement is active; or o a URL different from the current enhancement?s current topmost document if an enhancement is active. New enhanceme
26、nt triggers are used to initiate a new enhancement. From the no enhancement active state, an enhancement is initiated by a new enhancement trigger. An enhancement can only be initiated by a new enhancement trigger. Page 7 of 23 pages EG 39-2003 From the enhancement active state, a new enhancement tr
27、igger may replace the current enhancement with a new enhancement in an implementation specific manner. In order to ensure interoperable behavior, before sending a new enhancement trigger, an enhancement should be terminated by means of a viewerhrigger navigation which replaces the enhancements curre
28、nt topmost document with tv:. 4.3.2 Triggers for the current enhancement As shown in table 1, a trigger for the current enhancement is a trigger with a URL equal to the URL of the current enhancements current topmost document. Triggers for the current enhancement are used to: 0 0 terminate an enhanc
29、ement; 0 navigate to an enhancements next topmost document; change the display and/or state of an enhancement. In an enhancement active state, a viewerhrigger navigation to enhancements next document replaces the current topmost document of the enhancement with the contents of the enhancements next
30、document. With viewer initiated navigation, the current topmost document is replaced as the result of a viewer navigation (e.g., by means of a link) to another HTML document. With trigger initiated navigation, the current topmost document of the enhancement is replaced as the result of a trigger scr
31、ipt (such as: window.top.location.href=;) being executed. Such a trigger script is executed upon receipt of a trigger for the current enhancement. In order for the enhancement to receiver the trigger, the enhancements current topmost document must contain a trigger receiver object. NOTE - DDE-1 only
32、 requires the capability for running one enhancement at a time. Even though a new topmost document is being displayed, that document is still part of the current enhancement. However, note that triggers for the current enhancement delivered subsequent to the activation of the new document must have
33、a URL equal to the URL of the new document. If this is not the case, then either the trigger is ignored (if it does not have a name attribute), or may initiate a new enhancement in an implementation specific manner (if the trigger does have a name attribute). In order to ensure interoperable behavio
34、r, before sending a new enhancement trigger, an enhancement should be terminated by means of a viewer/trigger navigation which replaces the enhancements current topmost document with tv:. Note that triggers for the current enhancement may have a name attribute. A name attribute in a trigger for the
35、current enhancement does not initiate a new enhancement. Including a name attribute in a trigger can be used to achieve the following effect. If a viewer tunes to a program after the initial trigger for the programs enhancement was sent, then, by including a name attribute in subsequent triggers for
36、 that enhancement, the enhancement is initiated as a result of the receipt of a subsequent trigger. In the enhancement active state, an enhancement can be terminated by viewedtrigger navigation to tv:. More specifically, the navigation must replace the current topmost document with tv:. With viewer
37、initiated navigation to tv:, the current topmost document is replaced with tv: as the result of a viewer navigation (e.g., by means of a link) to the URL tv:. With trigger initiated navigation, the current topmost document of the enhancement is replaced with tv: as the result of a trigger script (su
38、ch as: window.top.location.href=tv:;) being executed. Such a trigger script is executed upon receipt of a trigger for the current enhancement. In order for the enhancement to receiver the trigger, the enhancements current topmost document must contain a trigger receiver object. An active enhancement
39、 may also terminate as a result of the receipt of a trigger to initiate a new enhancement. Please note that it is implementation specific whether, and in what manner, an Page 8 of 23 pages EG 39-2003 enhancement terminates upon the arrival of a trigger for a new enhancement. In order to ensure inter
40、operable behavior, before sending a new enhancement trigger, an enhancement should be terminated by means of a viewedtrigger navigation which replaces the enhancements current topmost document with tv:. The display and/or state of an active enhancement can be changed as a result of the receipt of a
41、trigger for the current enhancement. The enhancements display and/or state is changed as a result of the execution of the triggers script. 4.4 Cache management 4.4.1 Size Receivers are expected to provide buffering for one megabye (1 MB) of cached simultaneous content. Content creators who want to r
42、each the maximum number of receivers should manage their content such that the instantaneous high-water mark of simultaneous cached content is no more than 1 MB. All cache size values are the uncompressed sizes of the content stripped of all transport headers. Receivers may of course choose to store
43、 content compressed to reduce local memory utilization. When carried in IP Multicast and announced with SDP, the specific cache size required for each enhancement is required be specified in the announcement. The value of the SDP announcement extension, tve-size, represents the maximum size cache ne
44、eded to hold content for the current page at any time during the program including all pages reachable by local links. It is the high water mark during the program, not the total content delivered during the program. 4.4.2 Behavior The cache is generally be expected to operate according to RFC 2616
45、HTTP, sections 13 and 14. This provides the semantics for handling the required, as well as optional, HTTP header fields defined in UHlTP that can affect the cache behavior, such as expires. Expired content is not used or displayed, even if it is present in the cache when it was needed. The cache is
46、 flushed on receiver startup, but not on other conditions, including channel change, or even receipt of a new enhancement. Content that is delivered as a single entity is not entered into the cache until all sub-components are received. That is, when using IP multicast and UHTTP for delivery, and a
47、multipart entity is received, the individual content items would only be made available to the executing application if the entire multipart is successfully received and decoded. Partial cache updates may result in undesired composite page displays (Le., todays news headlines with yesterdays photos)
48、. 4.5 Cookies The general syntax for cookies is described in RFC 2965 HTTP-STATE, section 4.2.2, which consist of namehalue pairs. The names supported in DDE-1 are name and expires, with the latter being a date syntax defined as Wdy, DD-Mmm-W HH:MM:SS GMT. On powerup, a receiver should set the strin
49、g to null. The receiver buffer for cookies is 1024 bytes for session cookies. The cookie string supported by DOM-O document object concatenates the two namehalue pairs of multiple cookies into a single string. Page 9 of 23 pages EG 39-2003 On receipt of a UHTTP containing HTTP cookie fields, the name and expires namehalues are appended to the existing value of the cookie string. When the document.cookie property is read through DOM-O, it returns the entire string. When the document.cookie property is written to, its previous value is replace
