How TV-web gets to the TV

Active-TV Ecosystem Developers,

The Issue: Brining internet video to the TV is relatively easy compared to supporting the related TV UI and its associated application software.

Solutions: Other than Apple TV, all the entertainment ecosystem proponents are evolving to support Web 2.0 applications at the TV.

Behind the scene: For TV-web developers, understanding the competing technologies is essential in order to quickly reach a large living room TV audience. Active-TV technology continues to involve the simplest and most open path amid complex options.

Adoption of home networking is enabling the ecosystem approach to digital convergence to gain market share. The ecosystem enables internet video to be delivered to the TV, and also for the TV to gain access to PC-stored libraries of photos, video or music. The ecosystem is formed by networking a PC or notebook computer with Set-Top Boxes (STBs) Digital Media Adapters (DMAs) and networked TVs. The approach appeals to TV manufactures as it adds little complexity or cost to the TV, but provides access to PC-browser-based software applications.

Web 2.0
Reported in the NY Times is Microsoft’s introduction of Window Live. This is a package of browser based software applications, often referred to as Web 2.0 applications. According to the article: “Hundreds of companies in Silicon Valley are offering every imaginable service, from writing tools to elaborate dating and social networking systems, all of which require only a Web browser and each potentially undermining Microsoft’s desktop monopoly”.

The TV’s use of a networked PC as a remote computation engine enables Web 2.0 applications to appear as if they are ‘running’ on the TV. When web 2.0 applications are built for PC use, they rely on the keyboard and mouse for user inputs. When Web 2.0 applications are built for TV viewing, they make use of the TV’s IR remote to receive user inputs. Additionally, TV-web formatting does not use pop-up menus and small text or other formatting options unsuitable for TV viewing.

The list of those developing a browser-assisted approach to TV convergence includes: active-TV technology, DivX Connected and Microsoft Extender technology. I leave out Intel ViiV as it is not clear if they are still pursuing the approach or relying on one of the other suppliers. Apple TV is a partial ecosystem approach, as the Apple TV has more stand-alone capability. This is achieved at great cost and complexity for the Apple TV platform.

Inside a TV chip
To understand some of the technical difference between these approaches we have to take a quick look inside a TV SOC chip (TV System-on-a-chip). There are two ways they can present video and graphic images on the TV screen: One is via the built-in video decode engine; the other is via the small built-in 2D/3D graphics engine. Traditionally, a TV chip would receive a digital broadcast stream and send the video stream to the decode engine for TV display. TV schedule information, or Electronic Program Guide (EPG) data, is sent to the graphics engine for rendering into a TV image. TV chips have a means of combining the video and graphics images into a single TV-ready output. With the introduction of TV chips that support networking, video and graphics information can be sent to the TV via the home network in addition to broadcast reception.

Normally, Web applications run in the PC’s browser and the image is sent to the PC’s graphics engine for rendering and ultimately display on the PC monitor. With TV-web ecosystem support, the TV-web applications still run on the PC browser, but the image is sent over the network for display by the TV SOC. There are two ways to send the browser image over the network: one is to the TV SOC’s graphics engine, and the second is to the TV SOC’s video engine. Existing active-TV technology implementations and Microsoft Extender technology use the graphics engine approach. DivX Connected uses the video engine approach.

The graphics engine approach requires the TV SOC to have a larger than ‘normal’ graphics engine. This is likely why Microsoft chose the ATI Xilleon chip for use in its first Extender. But this was many years ago and there are now more TV SOC options with robust graphics engines. At the time, the Xilleon video engine only supported MPEG2 video decode. Now, however, there is a wide selection of chips which include support for MPEG4, WMV and H.264 video decode.

There are advantages and disadvantages to each approach. The video engine approach probably places more of a burden on the PC, particularly in terms of reducing the latency in TV UI response. Demands are also likely placed on the PC’s graphics card, which is likely used to assist with the video encode process. The burden also grows as the TV resolution improves, requiring high-def DivX video streams to be encoded and sent from the PC. However, the approach is possibly lighter-weight on the TV-SOC side, placing lesser demands on the graphics engine, integrated CPU or system memory. This may help reduce costs or ensure operation with lower-cost and less capable TV SOC options.

The video engine approach also makes it somewhat more difficult to support video ‘playing’ in a small window within a TV-web layout. (Microsoft calls this a video viewport). The problem can be solved by decoding the video then re-encoding into a single TV-UI DivX stream. Alternatively, the video viewport could be sent to the TV SOC as a separate video stream and then reassembled using Picture-In-Picture (PIP) technology. These complexities are likely the reason the DivX Stage6 TV-web UI does not currently support embedded video.

The graphics engine approach has the advantage of optionally combining video streams (decoded by the video engine) with TV-web images rendered by the graphics engine. This is particularly useful when supporting new forms of TV advertising via overlay TV web. The approach is under evaluation by several active-TV technology developers. Red Bee Media (formerly BBC Broadcasting) developed a prototype for IBC (Amsterdam) last year. The reduced PC-side burden may make the approach better able to simultaneously support multiple TVs in a single home network.

Some TV web pages (or channels) make calls on library support routines. With the introduction of the Media Center Edition (MCE) PC, Microsoft provided an API specification for these routines. The actual support code was included with a MCE PC purchase. The support code was not made available to Windows XP users. This may have encouraged purchases of new MCE PCs. TV-web channels, called Spotlights by Microsoft at the time, where written in HTML, formatted for TV viewing, and called on the API helper-routines.

An active-TV technology collaborator, MediaMall, built a version of the helper routines conforming to the same API. With the corresponding support code available to Windows XP users, TV-web sites can be viewed and more importantly sent over the home network to active-TV enabled TVs and Set-Top Boxes (STBs). There is no requirement to use an MCE PC or an Extender which relies on Microsoft’s Extender Technology – an alternative to active-TV technology.

The Xilleon TV SOC used in the original Extender only supported MPEG2 native video. Microsoft added support for WMV video by incorporating an ADI Blackfin co-processor to assist the Xilleon TV SOC. This enabled TV-web sites to utilize WMV video.

Active-TV collaborators have added PC-side transcode support for more video formats, including Adobe Flash (FLV) and DivX. This enables TVs using active-TV technology to display a wider range of video formats.

DivX has introduced its first DivX Connected DMA – The D-Link DSM-330. It is not clear if this is initially only for the European market. There is only support for DivX encoded video. The DSM-330 is based on a Sigma Designs chip. There has been criticism (1, 2) from possibly Microsoft-leaning reviewers on the limited video codec support. But there is no inherent limitation as to what video formats can be supported. Maybe the Extender did not include DivX support because Microsoft did not want to pay royalties to DivX. There may be some similar licensing rather than technology explanation for DivX’s decision. Few DivX enthusiasts will complain about the lack of WMV support.

This brings up a good point: all the available ecosystem technologies, active-TV, Extender and DivX Connected, can utilize the same TV SOC. This gives them equal access to native video codec support. They are all able to implement PC-side transcode. However, as seen with the latest active-TV platforms, the need for DivX transcode is eliminated when the TV SOC has native support. It will become increasingly difficult to differentiate ecosystem technology on the basis of native video codec support.

With the introduction of Microsoft’s next generation Extender technology, MCX v2, code named Pika, Microsoft is adding support for TV-web formatted with MCML (Media Center Mark-up Language). This will be supported by Vista Premium and Vista Ultimate PC platforms. Consequently, TV-web channels formatted using MCML will only be viewable to a portion of Vista PC owners; and since few of these are attached to a TV, the real audience is only Extenders supporting MCX v2 technology like the Xbox 360. Given the unattractiveness of this proposition, compounded by the continued sales of Windows XP and Vista Home, further reducing the number of new and existing PCs capable of supporting TV-web channels formatted using MCML, it is likely that TV-web developers will continue to use HTML formatting.

DivX Connected also uses HTML formatting, but rather than using the MCE API, a new set of helper widgets has been defined. These make calls on OpenGL support routines. This means that a TV-web channel formatted for DivX Connected may not work with the Microsoft’s MCX v2 ecosystem. However, given that TV-web channels used by active-TV technology and DivX Connected, both use HTML formatting, it can be possible for a single TV-web channel to selectively call the DivX support routines or alternatively the MCE support routines depending on the underlying ecosystem. Additionally, the use of these support routines can be greatly diminished by avoiding certain features, such as the use of video viewports.

DivX will provide a TV-web SDK (software development kit) for those building their own TV-web channel. Given that existing HTML-formatted TV-web channels can make MCE API calls which are not resolved by the DivX Connected run-time environment, it is difficult to support all of the existing TV-web channels using DivX Connected platforms. Fortunately, some of the MCE applications (such as those from Scendix) make little or no use of MCE API, so in this case the HTML formatting can be compatible with DivX Connected.

It will be difficult to get a large number of TV-web developers to switch to exclusive use of DivX formatted TV-web, unless there is a large number of DivX Connected platforms already sold. DivX’s primary TV-web channel is their own Stage6 portal. They will have to drive demand for their platforms via exceptional interest in Stage6. Simple support for TV access to PC-stored DivX video will not be enough to drive demand since it is likely that every TV-based ecosystem device (at least the active-TV ones) will already offer support for DivX video viewing.

In conclusion, like PC-web developers, TV-web developers can make use of Web 2.0 technology. Only HTML formatted TV-web ensures reaching the maximum TV audience. Adobe Flash combined with HTML and JavaScript is the ideal choice for TV-web development. While promoting the adoption of MCML and Silverlight, Microsoft must also continue to support original MCE and HTML technology with MCX v2, if it is to support its legacy of spotlight-formatted TV-web channels plus future HTML users. This reduces the key formats to HTML-MCE/active-TV and HTML-DivX Connected. The differences are diminished by avoiding unique ActiveX and MCE API features.

A single TV-web site could be compatible with both underlying technologies, although it may have to make selective calls depending on the browser user-agent. This is very much like the days when Netscape and Internet Explorer were in development and competing with new features. In the long run, however, devices and TV-web channels will likely coalesce around the most pervasive and familiar of formats, namely HTML with Flash, thereby spawning wide adoption of Web 2.0 applications from the TV.

Feedback, corrections and comments welcome. Contact me for more information or support with active-TV technology development.
Daniel Mann