Microsoft DirectX 8.1 (C++)

Adding Support for New Network Types

Microsoft� TV Technologies provides default support that enables applications to tune to American Television Standards Committee (ATSC) and Digital Video Broadcasting (DVB) digital television networks. In the filter graph, this support is provided by the ATSC or DVB Network Provider filter (see BDA Network Provider), the BDA device filters that represent the hardware, the MPEG-2 Demultiplexer, and the BDA MPEG-2 Transport Information Filter (TIF).

Third parties that deliver MPEG-2 based networks that do not conform to the ATSC or DVB standards may need to extend Microsoft TV Technologies by implementing a custom Transport Information Filter that supports the Packet Identifier (PID) mappings for the network. This filter will participate in the filter graph in addition to the default TIF, with a separate pin connection to the MPEG-2 Demultiplexer. In rare cases, support for a non-standard network type may require a custom Network Provider filter, but this is generally not recommended. The following overview is provided for developers who are creating a custom TIF or Network Provider. The details discussed here are generally not relevant for application developers.

To understand the concepts discussed in this section, you should be familiar with The Microsoft Unified Tuning Model, the filters in a Digital TV Filter Graph, and the Video Control and Guide Store.

How the Network Provider Helps Build the Graph

When the application submits the tune request to the Video Control by using the IMSVidCtl::View method, the Video Control examines the network type GUID of the tuning space associated with the tune request. That GUID is matched to the GUIDs for the ATSC Network Provider and the DVB Network Provider, and the Video Control adds the appropriate one to the BDA filter graph. (See Microsoft TV Technologies Internals). When the user calls Build, or Run (which calls Build internally), the Video Control builds the graph by finding the available Broadcast Driver Architecture (BDA) devices and querying the Network Provider whether each device is appropriate for the graph. The Network Provider filter is responsible for determining the proper sequence of BDA device filters in the filter graph. After the graph has been built through to the MPEG-2 Demultiplexer (Demux) and the Transport Information Filter, the Network Provider acquires the interface pointers on those filters that it will use to complete the tuning process. For more information on this process, see Transport Information Interfaces and BDA Filter Interfaces.

Acquiring Additional Locator Information

Once the graph is built out through the BDA device filters, the MPEG-2 Demultiplexer (Demux), and the BDA Transport Information Filter (TIF), you can begin the tuning process and obtain additional information about the transport stream that may or may not be present in the tune request. If the tune request contains sufficient locator information, then the Network Provider can tune the BDA tuner device to the correct frequency and set the correct inner and outer forward error correction (FEC) rates, symbol rates, and so on, so that the transport stream can begin flowing to the Demux. If the tune request does not contain locator information, then the Network Provider falls back to a default locator for the tuning space.

Once the transport stream is flowing, assuming it is a standard ATSC or DVB MPEG-2 transport stream, the Demux sends the Program Association Table (PAT) packets to the TIF. The TIF reads the PAT and then sends an event to the Network Provider indicating which PIDs the PMTs and other tables are on. If the tune request is for another transport stream on the network (which will be the case if you have used the default locator on a DVB network), then the Network Provider will again tune the device using the PMT information. If you are delivering transport information tables on non-standard PIDs, then at this point in the process, your custom TIF will need to provide the correct PIDs to the Network Provider.

 Obtaining Component Information

Once the locator information is completely resolved and the correct transport stream is flowing through into the Demux, the Network Provider queries the TIF for the component information, that is, the PID values for the audio, video, data, and text streams for the requested service. The TIF returns this information to the Network Provider, which forwards it to the Demux, which can then begin routing the various streams to the decoders and the data services graph segment.

Changes in Transport Information Tables

The Demux routes the transport information tables to the TIF, which continues to examine them. If it detects any changes, for example a service goes away or a new one becomes available, the TIF fires an event and gives the Network Provider a chance to request an update to the component list in the tune request, and to forward this information to the Demux. The TIF also receives the in-band EPG information, and it provides interfaces to enable a Guide Store Loader (Loader) to access that EPG data as it arrives.