| Close |
| Comment |
| Close |
| Comment |
The growth of new media formats such as the vector graphic formats Flash and MPEG-4, and streaming formats such as QuickTime, Real, and Windows Media offer a number of new options to those wishing to produce interactive television applications. During 2002, WGBH conducted two technology tests with streaming formats, and tests of Flash-based programming and streaming audio content via DTV datacast.
Case Study 1: Transmitting Flash based programming via DTV datacast
Vector formats such as Flash can be utilized in two ways, as part of an existing ITV application in systems such as Liberate and the recently introduced Moxi/Digeo platform, or as a medium for the programming itself. Because the use of vector formats in web based applications is well understood and documented, this trial concentrated on issues surrounding distribution of vector-based programming.
Vector formats have two advantages over standard video formats. The first is file size. Rather than transmitting a series of still images, vector graphics are formed by transmitting a set of instructions ("vectors") detailing how to draw the images. As a result, data rates for animation comparable to typical children's programming run as low as 50 Kilobits/second as compared to the 3-4 Megabits/second generally allocated in the ATSC stream for video. While these numbers are to some degree skewed by the fact that vector graphics are only the video portion of the signal and do not include audio or any additional interactivity that might be bundled into the program, even if we assume an additional 150 Kilobits/second we are still looking at a data rate of 200 Kilobits/second; less than one tenth of the current bandwidth allocation. Secondly, many vector based formats, such as Flash and MPEG-4, support interactivity, allowing the producer to build interactive sections directly into the program. This functionality can be used for creating anything from a simple educational game to hyper fiction style navigable storylines.
Generally speaking, vector applications are compiled into a single piece of software bundling audio, graphics, and interactivity into a single package. In order to play these applications, the user needs a receiver capable of rendering them. This receiver also needs the ability to receive data via either straight IP, such as modem or Ethernet or DTV datacast. Currently the only receivers that meet these requirements are PCs equipped with ATSC Data receiver cards.
At a basic level, transmitting vector based data such as a Flash application via DTV datacast is a simple affair. Data is inserted into a known PID in the ATSC digital stream and is received on a compliant receiver via UHHTP at the other end. However beyond this, there were three issues we addressed in this trial:
These three issues were solved by developing a small Flash based viewer application that would be resident on the receiver and would handle management functions.
Concerning cache size, our solution was to slice the Flash application up into small component pieces that would fit into the cache. Maximum size of these applications was 512k so two clips (one playing and one loading) could fit into the cache. The viewer application would play the currently loaded clip and proceed seamlessly to the next clip. Because the cache structure is defined as first-in first-out, additional housekeeping functions were not necessary.
The next issue was programming time; does the show need to be transmitted at a given time, and if this is the case, what happens if a viewer tunes in late? It was decided that we should try to emulate broadcast television in that a given show would only be available at a particular time. While the recent growth of VOD and PVRs make this scenario somewhat less relevant, as the saying goes, it "seemed like a good idea at the time".
In a normal television environment viewers tune to a channel and instantaneously receive video. In a Flash scenario it is necessary to load some amount of data before the application can play. Our answer to this came from the insanely fast transfer rates possible in DTV datacasting. For our tests we had allocated 1 Megabit/second (0.125 megabytes/second) in the DTV steam. Upon "tuning in," a 275 KB, 30 second, opening credits file downloaded in less than three seconds. This file played while the first segment of the program was downloaded.
The above scenario also solved the "tune in late" issue. The "intro" segment was scheduled in the data insertion software so that it would always be available to the application. This had two effects. First, it required us to downsize our segments to less than 374 KB each so that there would be space in the cache for two segments and the intro piece. Secondly it was necessary to build a default behavior into our viewer application that would always play the intro clip.
The third issue, the required number of repetitions to ensure transmission, appeared to be a non issue. Reception tests were conducted approximately ten miles from the WGBH transmitter under generally clear weather conditions, so it is unclear the kind of results that would be obtained under less favorable conditions. However at 1 Megabit/second the entire cache is refreshed every 8 seconds allowing for three complete transmissions during the time the intro section is played.
Reception was accomplished using a Triveni Datareceiver Hardware/Software combination. This application received data from the DTV stream via UHTTP and placed it in a known directory. Files written to this folder only become "visible" upon completion. Accordingly, the viewer application was designed to periodically "poll" this location for completed files, which were then made available to the user.
Case Study 2: Transmitting streaming content via DTV datacast
Streaming formats such as QuickTime, Windows Media and Real offer, via file formats such as SMIL and authoring packages such as the Live Stage product for QuickTime, a level of interactivity found only in the most advanced interactive television applications. This trial was focused on delivering streaming audio via DTV datacast, however the processes and technologies involved the insertion of streaming media into the DTV stream and tests of PC based receiver cards. These processes have clear implications for deployment of interactive television. Furthermore, audio services will almost certainly be a significant element of any integrated ITV service deployed in the future.
The genesis of this trial was the continued growth of streaming audio via IP in WGBH's radio affiliate WGBH-FM. While this growth has been good for WGBH-FM in that it has expanded listenership and allowed the station to present a wider range of services, Internet-based streaming carries with it a large, per user, incremental cost. Broadcasting, on the other hand can serve every person in range of the transmitter with no per-user incremental cost. WGBH and many other Public Television stations have under-utilized DTV transmitters that could easily transmit streaming audio, and many of these were Dual (Radio/TV) licensees, so this seemed to be a good marriage. It should be noted that while our tests concentrated on streaming audio, they are equally applicable to video and other streaming formats.
Our tests included the three major formats in streaming: Real, Windows Media Player and QuickTime. In this trial, we used the free versions of each format's server. This worked for QuickTime and Windows media, but we found that for Real it was necessary to use the "professional" streaming product which costs thousands of dollars. Fortunately there was one available in-house for our tests.
The WGBH-FM program audio feed was run to the audio input of a streaming server. The server converted the audio to the appropriate streaming format and transmitted it as multicast feed on a known multicast address across our in house LAN. This multicast was then received by a Triveni Skyscraper system which inserted the multicast feed into the DTV stream.
It should be noted that DTV datacast relies of "carouseling," that is the process of inserting data into the DTV stream multiple times to insure reception on the receiver end. The UHTTP protocol contains error correction which is designed to receive data multiple time and reconstruct it in case of drop outs. This has implications for streaming, namely that multiple repetitions of a given program stream raise the required data rate. Initial testing seemed to indicate that multiple repetitions of a program were not necessary, however these tests were carried out under favorable weather conditions at a distance of less than 10 miles from the transmitter and may have been effected by any built in error tolerance in the player software. Accordingly the need for carouseling in this type of deployment is still an open question.
Data Receiver cards from five manufacturers, AirCode, AccessDTV, B2C2, Hauppauge and Triveni were tested. These were installed in a variety of PCs ranging for a venerable IBM PII 300 to a (then) recent vintage Dell PIII 800, running either Windows 98 or 2000. Reception was tested with two feeds, a commercially available "Silver Sensor" antenna and the WGBH in house antenna feed. Data was captured using software provided by the card manufacturers. This software either caches data on the hard drive or creates a separate virtual IP address. The appropriate player application was then pointed to either one of these locations.
This trial was in many respects very easy. Products worked "as advertised." However we did find a few wrinkles that would need to be addressed in a real world deployment. Primary among these problems was the issue of proper installation and set up of the data receiver cards. Of the five cards we tested, we were able, with various degrees of difficulty, to get four to work. However the people involved with the installation were users with a very high degree of technical knowledge as opposed to the typical consumer. Additionally, we knew exactly what we were looking for as far as a specific PID in a specific stream on a specific frequency.
While the initial thrust of this trial was directed at switching users from receiving programming on PCs via IP to receiving programming on PCs via DTV datacast, deployment of this technology on home entertainment devices would make this content more widely available to consumers and, with the addition of PVR technology, would allow for more efficient use of broadcast spectrum by enabling broadcast of content that has wide listener interest on "off" hours. Additionally, these services could be subscription based, creating a new revenue stream, and could also be enhanced with additional media in a similar manner to television programs. Finally, the availability of a wider range of transmission options would also allow servicing smaller media outlets squeezed out of the radio spectrum by recent FCC deregulation.
Conclusions: Moving towards deployment
While both vector and streaming technologies have seen wide deployment on the PC platform, a viable business model has yet to emerge. However, the emerging "convergent" home entertainment centers and next generation set top boxes beginning deployment on some cable systems may, by virtue of a more convenient viewing environment and wider deployment, offer the possibility of not only the emergence of a viable business model, but new service opportunities for public broadcasting as a whole. However there are a number of problems which must be dealt with for this scenario to become a reality.
Streaming and vector technologies generally require a proprietary player which have yet to make their way to set top boxes or consumer electronics devices in any number. Additionally, in order to receive these applications, a box would need some form of IP connection, modem, Ethernet or DTV data. Consumer electronics and set top box manufacturers are further integrating IP connectibility and net technologies into their next generation devices while "media center" type computers, such as the Windows Media Player based HP system, are seeing unexpectedly high sales. While this technology is in an early stage of implementation on these devices, and is focused largely on more basic media such as MP3s and digital photographs on the consumer side and VOD and electronic program guides on the commercial side, the movement is definitely in the right direction.
Beyond the consumer availability of devices capable of playing this kind of content there is still the problem of deployment. No one knows what an actual deployment of these kind of services would look like, but it is possible to make a few educated guesses. IP addresses and datacast times, PIDs and frequencies could be made available in a format similar to current scheduling information and would be integrated into the electronic program guide. Programming would be accessed via the EPG either live, pseudo live (i.e. pre-cached for instant access), or could be scheduled ala TiVo. To the user this process would be exactly the same as selecting a channel or selecting a VOD movie, but with a much wider selection of content from a variety of sources.
Revised Tuesday, 25-Feb-2003 18:04:20 CST - h -
© 2000 - 2003 Local Enhancement Collaborative & 
-
Please Comment