Microsoft Corporation
June 1999
Summary: Broadcast Services (BCS) for the Microsoft® Windows® CE operating systems is a high-performance application interface that extends Windows CE capabilities to include broadcast audio/video services, conditional access processing, Electronic Program Guide (EPG) infrastructure, and broadcast data handling. BCS supports development of embedded applications for cable and satellite set-top boxes, enabling providers to meet the many sophisticated, market-driven needs of the broadcast television customer. This article describes each of the four subsystems that comprise Broadcast Services and provides information about how to implement the subsystems on the set-top box. This article is intended for developers (14 printed pages).
Introduction
Broadcast Services ActiveX Controls
BCS Architecture Overview
Introduction to Conditional Access
Application Programming Interfaces
Conclusion
For More Information
Microsoft® Windows® CE is a compact, scalable operating system that enables development of embedded systems, such as for the cable set-top box. Windows CE uses a subset of the Microsoft Win32® application programming interface (API) commonly used on Windows-based desktop and server computers. Broadcast Services (BCS) adds components to the Windows CE operating system that enable television broadcast suppliers to develop systems to:
BCS assures accessibility to the developer community by using current Microsoft technologies, such as customized Microsoft ActiveX® controls and current Microsoft DirectX® services. Furthermore, BCS provides broadcast suppliers with a flexible architecture that both supports evolution in set-top box hardware design and also protects applications from operating system changes. BCS supports analog, digital, and high-definition television (HDTV) streams, enabling:
For the interactive home networking environment, BCS will enable support of digital recording and multiple tuners and external devices, such as VCRs for one-step VCR recording from EPGs. One-step recording will be available once the Reminder feature of EPG is fully implemented. BCS is compliant with both U.S. and European industry standards, such as:
BCS extends the Windows CE operating system through an API of ActiveX controls that enable broadcast suppliers to meet the market-driven needs of television broadcast consumers. You can either write Web applications using DHTML, ECMAScript, or Microsoft JScript® development software, or develop native applications using a programming language, such as Microsoft Visual Studio® or Microsoft Visual C++®. BCS ActiveX controls simplify the process of creating integrated, well-designed BCS applications.
The Windows CE BCS API enables television broadcast suppliers to develop applications that bring interactive television to their customers. BCS supports development of applications that integrate the television with the Internet, and provides access to remote data stores, such as for customer authentication and authorization or for television programming schedules.
You can develop BCS applications to enhance what customers love to do most with the set-top boxes – watch TV! Enhanced applications include integrated EPG, parental controls, controlling the VCR, web browsing, e-mail, and so forth. This also includes visual effects, such as combining the broadcast stream with other graphics to make display capabilities easy to use. You can create applications that display on-screen program schedules without forcing the user to change channels. Users can easily view and choose among programming options on dozens of stations available to broadcast customers, without having to suspend the program currently playing. Not only can an application display a translucent electronic program guide over the TV video, it can display the TV video through an embedded window on a Web page that contains other text and graphics.
With the BCS API, broadcast suppliers can also control whether a user receives a channel or a program just as they do with today's set-top boxes. However, because of the rich environment and power of BCS, you can create a new generation of pay-per-view (PPV) and impulse PPV, to maximize the business of the premium tiers and paid-for programming. The BCS API is the focus of this article.
This article provides information about the Windows CE Broadcast Services API of ActiveX controls and how to implement them in applications for the set-top box. Such applications may be designed to:
BCS provides a powerful set of services by building on the Windows infrastructure using ActiveX controls, Microsoft DirectShow™, Microsoft DirectSound®, Microsoft DirectDraw®, standard Windows CE Device drivers, ActiveX Data Objects for Windows CE (ADOCE), Network Driver Interface Specification (NDIS), and TCI/IP. BCS adds components to the operating system for A/V stream management, EPG services, and conditional access (see Endnote).
BCS provides four major services:
The following illustration provides an overview of the architecture of the BCS subsystems. BCS uses the standard Windows CE device driver model. The drivers are written by the Original Equipment Manufacturer (OEM) and are executed by Device.exe. See Figure 1.
Figure 1. Overview — architecture of BCS subsystems
Applications use the TVControl ActiveX control to select broadcast audio and video streams for display. The TVControl uses the A/V manager, which coordinates the BCS subsystems. Applications do not use the A/V manager interfaces directly.
The A/V manager uses a DirectShow filter graph to manage the broadcast streams. Filters expose well-defined interfaces for controlling specific aspects of decoding and displaying broadcast audio and video. Filters provide a mechanism for hardware OEMs to add value while not disturbing the rest of the software architecture. The filters can be used to address the specific hardware, or they can be used to provide software services, such as a software decompressor. OEMs provide the filters and hardware drivers.
Broadcast video is combined with locally generated graphics or Web pages by using DirectDraw. The application may use DirectDraw surfaces.
Implementing DirectShow on the desktop computer differs from Windows CE; the desktop computer uses the Windows driver model, whereas Windows CE uses the Device.exe device drivers. The Windows driver model does not exist in Windows CE.
The Broadcast Data architecture organizes data in two ways. First, the Broadcast Data facilitates the drivers that receive data by offloading most of the data interpretation chores and providing a simple, low-level interface for delivering data. Second, Broadcast Data also facilitates the applications that use the data by providing a collection of interfaces that simplify broadcast data reception. The application has a choice of three interfaces through which it can access data. It can fetch data directly from Winsock; it can receive data from a COM interface; or it can have the data compiled into a table that it reads directly. Broadcast Data supports three categories of data, which:
V-chip data interpretation provides an example of how Broadcast Data facilitates drivers and applications. The analog TV VBI Line21 driver and the digital TV Picture User Data driver both produce Line21 byte pairs, which they deliver to the Broadcast Data Services without further processing by the driver. Broadcast Data Services demultiplexes and adds these two bytes into an Extended Data Services (EDS) message. When EDS messages are complete, they are sent to NDIS, UDP/IP, and Winsock. If the application is waiting at the Winsock interface, it receives the EDS message. If the application is using the COM interface, it receives a callback with the EDS message. In both cases, the application must then parse the data for the V-chip information. If the application is using the Tabler interface, it receives a callback containing a program information structure from which it can easily read the V-chip information.
The term conditional access (CA) refers to restrictions placed on the viewing of TV broadcast content. These restrictions include policy limits relating to ratings or viewing time, restricted access to subscription-based services, and PPV services.
Windows CE Broadcast Services provides a CA API, which allows applications to receive and respond to CA-related errors and to manipulate purchasable items in a manner independent of the underlying CA technology.
BCS allows CA systems to communicate with both the CA applications and the rest of the BCS system. The CA subsystem supports the following services:
Applications initiate usage of CA services through the TVControl ActiveX control. TVControl allows control of the user interface for customer interactions required by the CA system.
The EPG services collect transient and remote guide listings data and store it to provide fast, rich, read-only querying capabilities. The application developer accesses the guide listings data through the EPGControl, a non-visual ActiveX control that gives applications easy access to the EPG data, without having to know the underlying database schema. The EPG infrastructure consists of five main components:
The EPG infrastructure provides a standard way to access EPG data from BCS. The EPG database can be built using the Windows CE file system or any database that supports ADO.
The EPG services themselves do not provide a graphical representation of the data. The application developer must implement the graphical interface.
The system integrator provides one or more EPGLoaders to collect guide-listings data from in-band or out-of-band television signals, from HTTP or FTP, from TCP/IP sockets, or from any other communications protocol. The EPGLoaders use the EPGControl to read data stored by EPG services and compare it to the incoming data. If necessary, the EPGLoaders add new data to the EPG services store through the EPGWriter. EPG services enable the following functionality:
The TVControl scripting interface makes it easy to use Broadcast Services from an HTML environment. Typically, you declare your TVControl object as shown in the following JScript® sample code. The CLSID must be as shown:
<OBJECT CLASSID="CLSID:C82FB020-62D1-11D2-98DB-0060083176E3" ID=TVControl>
<SCRIPT LANGUAGE=JScript>
TVControl.TuneChannel(0, 20); // Tunes to Channel# 20
</SCRIPT>
The TVControl is a windowless control. This means that it needs to be used from an application or a browser that hosts the control and then displays the video in the region of the window of that application or browser. The advantage of this windowless control is that the control can display video in any region, as programmed by the application or browser. Fewer resources being consumed and faster activation/deactivation lead to performance advantages.
For this version, only one instance of a TVControl is permitted. In the future, multiple instances of the TVControl will be supported.
The EPGControl scripting interface makes it easy to use EPG services from an HTML environment. Typically, the EPGControl object is declared as in the following JScript sample code:
<OBJECT CLASSID="CLSID:C653DFC8-9884-11D2-9299-00A0C9C9E689" ID=EPGControl>
<SCRIPT LANGUAGE=JScript>
if (EPGControl.IsAnyDataAvailable) // Check EPG store for data.
{
// Continue.
}
</SCRIPT>
The next sections present an overview of the BCS ActiveX control APIs.
TVControl is an ActiveX control that provides the application interface to the A/V manager. Applications can be written in a suitable language, such as JavaScript, ECMAScript, JScript, or Visual C++. The A/V manager runs in the background and has access to all the devices. A user controls the A/V manager through the TVControl.
When using the TVControl, the user can change channels with a remote control, as with a traditional TV. In the interactive world, there are new possibilities for changing channels. For example, channels can be changed by going to a Web page for a particular network. The page might use a TVControl and provide a window within the Web page tuned to the local affiliate. Figure 2 illustrates what the TV screen might look like.
Figure 2. Tuning criteria using TVControl
The TVControl can tune by channel, station, network, source identifier, and selector identifier. For additional tuning criteria, you should use the EPG control to map to TVControl properties. TVControl provides other features in addition to changing channels. Applications can use the TVControl to:
The EPG controls are ActiveX controls that provide applications with easy access to the guide data without requiring them to directly access an underlying database schema or raw data stream. The EPG services collect transient and remote guide listings data and store them to provide fast, rich, read-only querying capabilities.
The EPG database is automatically constructed by the EPG services to update the guide database. The EPG will be a primary application built for a set-top box. It can access all broadcast stream-handling services using the TVControl. Figure 3 provides an example EPG with live video embedded in the upper-right corner of the guide.
Figure 3. EPG with embedded live video
You can access the guide listings data through the EPGControl, a nonvisual ActiveX control that provides abstracted access to the data store. The EPG services themselves do not provide a graphical representation of the data, as shown in the above illustration. You must implement the graphical interface.
The following illustration in Figure 4 shows an overview of the EPG services architecture.
Figure 4. Overview — EPG services architecture
The system integrator provides one or more EPGLoaders to collect guide listings data from in-band or out-of-band television signals, from HTTP or FTP, from TCP/IP sockets, or from any other communications protocol. EPGLoaders use the EPGControl to read data stored by EPG services and compare it to the incoming data. If necessary, the EPGLoaders add new data to the EPG services store through the EPGWriter.
A description of the EPG ActiveX controls follows.
EPGControl—Performs queries and retrieves information about channels and schedules.
EPGWriter—Stores collected guide listings data in the EPG services data store so that the data can be queried and retrieved by the EPGControl.
EPGDataMap—Obtains necessary data for the A/V manager from the EPG services. This interface should not be used by EPGLoaders or other applications or components developed by system integrators or application developers.
Although the device capabilities will determine the amount of local memory or disk storage available for guide listings data, with EPG controls you can modify the amount of data stored on any of the following axes: time, channels, language, or richness.
For example, for richness you can modify the amount of data stored for titles, descriptions, and other program description attributes. Figure 5 provides an example of richness scaling.
Figure 5. Example of richness scaling
The richness of program information can vary according to title, description, and other attributes (for example, closed-captioning). In addition, if a channel is designated as a favorite channel, the richness of programs on this channel can be specified independently.
The EPG services architecture is flexible and allows for new sources of data and new data sets.
As new sources of data become available, you can add additional EPGLoaders. For example, a new EPGLoader can be written to collect movie review data from an HTTP address.
In addition, as data sources add new properties to guide listings data, EPGLoaders can be modified to add this new data to the EPG services store. A modified graphical interface application can then retrieve the data.
Extensible properties can be added to the channel, program, schedule entry, or Web link data. Multiple properties can be added to the same data set.
New properties are stored and retrieved using a flexible name-value scheme. Each new attribute is named, and the value is stored along with that name. Values are stored and retrieved using a textual string representation. Applications can convert this string value back to its native format using the C/C++ VARIANT class or through JScript constructors that take a string.
For example, an EPGLoader can add a new program property named RogersReview to all programs with the values THUMBSUP or THUMBSDOWN. The graphical application can then use the EPGControl to request the value for RogersReview for any program. Because the extensibility mechanism supports multiple properties, a second property can also be added named FidosReview, with values such as PAWSUP or PAWSDOWN.
EPG Controls provide other features in addition to scalability of data and extensibility.
Applications can use the EPG controls for:
The CA controls are ActiveX controls that enable applications to monitor conditional access privileges. CA controls allow applications to receive and respond to CA-related errors and to manipulate purchasable items independent of the underlying CA technology.
BCS also provides a COM-based interface, which allows CA systems to communicate with the CA applications and the rest of the BCS system. The CA subsystem supports the following services:
Applications initiate usage of CA services through the TVControl ActiveX control. TVControl allows control of the user interface for customer interactions required by the CA system. The OEM must provide a CA service provider.
With BCS, conditional access providers can:
For example, purchasing applications can contain the business rules, whereas the CA interfaces transmit only necessary data. This enables broadcast suppliers to respond quickly to market opportunities. They can change the business rules without changing the Windows CE operating system and without changing the CA system software.
The BCS CA subsystem enables broadcast suppliers to develop new classes of premium content applications and purchasing applications while independently evolving the underlying CA technology. This allows for continuous improvement and enhancement in performance and features offered.
The CA subsystem in BCS provides an abstraction layer between entitlements enforced by hardware installed on a host set-top box, a limits policy, and the application.
Figure 6 provides an overview of the CA subsystem architecture.
Figure 6. Overview — CA subsystem architecture
The application discovers and manipulates CA-related information via a set of four ActiveX controls with common interfaces. By exposing CA functionality in a generic fashion, applications can separate themselves from the details of the CA hardware and limits policies. Furthermore, CA suppliers can upgrade their CA systems, independent of the applications. A description of the CA ActiveX controls follows.
CAErrorSource—Fires ActiveX events into the application when an access denial occurs. This control allows the application to discover and process denial events regardless of whether the TVControl is hosted by the application directly or inside a Web page hosted by an application.
CAOfferItem—Represents a purchasable item. It can be instantiated from a Web page through a string of data. Purchasable items can also become apparent to the application through a CAError or the CAOfferList control.
CAOfferList—Defines a simple, uniform way to access and search through pending offers and recently purchased items.
CAProviders—Allows the application to enumerate and query the provider software modules currently installed in the set-top box.
Provider modules are DLLs that are enumerated in the system registry and loaded by the CA manager at system start time. The interface between the provider modules and the CA manager is called the service provider interface (SPI). The SPI enables:
To integrate a CA system into BCS, the CA provider must author a provider software module. Additionally, to implement policy limits, a special provider software module—the Limits Provider—must be developed. Although many CA provider software modules may be active in the system at once, only a single Limits Provider is allowed.
Provider modules can be identified by a ProviderID globally unique identifier (GUID), which is listed in the registry with the rest of the provider module configuration information. ProviderIDs are used in OfferStrings, which are external representations of purchasable items. ProviderIDs are exposed to the application in error information and are exposed by means of the CAProviders control.
Based on trends in the industry and market-driven needs, television broadcast consumers expect greater integration of their televisions with the Internet. BCS extends the Windows CE operating system so that broadcast suppliers can develop interactive applications that meet the needs of their customers. With BCS ActiveX control APIs, you can easily design and build applications to run on set-top boxes, offering customers functionality such as electronic program guides, conditional access monitoring, and targeted programming based on viewer profiles.
With the BCS APIs, you can create programs to meet these needs and look toward the future needs of the television broadcast consumer. The BCS architecture is flexible enough to support proprietary systems where vendors can offer additional features, control functions, and services that create a very compelling, integrated experience for the home television viewer.
For more information about Windows CE, see the Microsoft Windows CE Web site at: www.microsoft.com/windowsce/default.asp.
For more information about Broadcast Services for Windows CE, see the Windows CE Set-Top Box Guide and Reference supplied with the Set-Top Box Kit.
Conditional Access (CA) refers to restrictions placed on the viewing of TV broadcast content. These restrictions include policy limits relating to ratings or viewing time, restricted access to subscription-based services, and pay-per-view (PPV) services.
--------------------------------------------
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only.
This article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, ActiveX, DirectDraw, DirectShow, DirectSound, DirectX, Jscript, Visual C++, Visual Studio, Win32, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.