Contentsdownload.microsoft.com/.../PBDA-Scanning.docx · Web viewThis is because the EIT data sections must be extracted and reformatted into the PBDA specification SI format. The

In-Band Delivery of Guide Data in PBDAOctober 29, 2010

Abstract

This paper provides information about the in-band delivery mechanisms for guide data in the Protected Broadcast Driver Architecture (PBDA). It also provides guidelines for developing PBDA-based in-band scanning solutions that load services or schedule guide data in Windows Media® Center.

This paper is intended for independent hardware vendors (IHVs) and independent software vendors (ISVs) of PBDA-based tuners.

This information applies to the Windows® 7 operating system.

References and resources discussed here are listed at the end of this paper.

The current version of this paper is maintained on the web at:http://www.microsoft.com/whdc/device/broadcast/PBDA/scanning.mspx

Disclaimer: This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. © 2010 Microsoft Corporation. All rights reserved.

http://www.microsoft.com/whdc/device/broadcast/PBDA/scanning.mspx

In-Band Delivery of Guide Data in PBDA - 2

Document History Date ChangeOctober 29, 2010 First publication

ContentsContents........................................................................................................................2Overview........................................................................................................................3In-band Scanning...........................................................................................................3

Dynamic Selection of Scanning Type.........................................................................4Exhaustive Scanning..................................................................................................5

Configuring the PBDA Tuner for Scanning.............................................................5Scanning the Frequency Bandwidth by Using PBDA..............................................8

Guide Data Delivery Service Scanning.....................................................................11Communication Protocols...................................................................................12Automatic Merging of Services and Schedule Guide Data..................................13Download Guide Lineup on Headend..................................................................13Periodic Scanning................................................................................................14In-band Guide.....................................................................................................14Services and Events.............................................................................................15Merging Services Based on the MatchName Service Attribute..........................15Services and Schedule Updates and Versioning..................................................17EIT Present/Following Updates...........................................................................17MMI Messages for the Guide..............................................................................17

GDDS Usage Scenarios and Examples......................................................................18Example 1: GDDS In-band Guide Delivery for a DVB-C network..........................18Example 2: GDDS In-band Guide Delivery by Using ChannelID...........................20

Conversion from DVB-SI EIT to PBDA-SI for GDDS Delivery.....................................21Troubleshooting Possible Issues during Development................................................21Resources....................................................................................................................22Appendix. Glossary and Acronyms..............................................................................23

October 29, 2010© 2010 Microsoft Corporation. All rights reserved.


OverviewWith the introduction of the Protected Broadcast Driver Architecture (PBDA), Windows Media Center supports new capabilities to do the following:

Scan tuners, which were previously configured for operation with Windows Media Center, for the guide data of services and schedule.

Retrieve and load this data into Windows Media Center.

Windows Media Center loads guide data for services or schedule by using the following methods: Windows Media Center can access the guide data through an out-of-band

method by downloading the data through an Internet connection. After the data is downloaded, Windows Media Center updates the local guide storage with the latest services and schedule for the configured region and tuners.

During live TV setup or periodically after that, Windows Media Center can access the guide data through an in-band method by scanning configured tuners. In this way, Windows Media Center can retrieve current services or schedule guide data from the tuners.Note: Live TV setup in Windows Media Center is referred to as first run (FRUN) in the PBDA Specification.

The methods for loading guide data are independent but also work together. You can use either or both methods, and Windows Media Center will merge the guide data from both sources.

The advantage of the out-of-band method is that it usually provides richer details and a longer span of guide data because it is from the Internet and has a less limited bandwidth. The advantage to the in-band method is that it can provide up-to-date guide changes because it can arrive at any time and is not limited to the periodic download time by Windows Media Center. Using both methods provides the best user experience by giving the richest, most complete, and most up-to-date guide data.

Out-of-band delivery of guide data is supported by Windows Media Center, while in-band delivery is supported by the tuner. This document provides guidelines for independent hardware vendors (IHVs) and independent software vendors (ISVs) to implement in-band methods in their tuners for delivery of service and schedule guide data.

In-Band ScanningWindows Media Center can use the following methods to load in-band service and schedule guide data from configured tuners: Classic scanning. For various known digital TV standards such as Digital Video

Broadcasting (DVB), Integrated Services Digital Broadcasting (ISDB), and Advanced Television Systems Committee (ATSC), Windows Media Center loads specific plug-in modules that support guide loader for in-band data (GLID).



For a specific tuning space or network type, Windows Media Center loads a predetermined set of physical parameters (such as frequency/channel map, frequency/transponder map, or other appropriate mapping), and iteratively sends tune requests to the tuner to acquire the services and schedule guide data by using in-band delivery methods.

Exhaustive scanning. For various digital TV (DTV) standards (such as DVB, ISDB, and ATSC), Windows Media Center loads specific GLID modules. If the tuner implements the exhaustive scan interface, tuners are able to scan and lock on to frequencies on their own instead of using built-in tables of frequencies. This is a more time-efficient method than classic frequency-based scanning.

GDDS scanning. For PBDA tuners of any DTV standard, the Guide Data Delivery Service (GDDS) offers a third option to transfer a list of services and associated guide information for these services. This method does not use frequency-based scanning but relies completely on the data transfer from a tuner to Windows Media Center for services or schedule guide data.

This paper focuses primarily on the exhaustive scanning and GDDS scanning methods. It is written for both IP-based or kernel stream (KS)–based PBDA tuners. For more information about IP-based and KS-based PBDA tuners, refer to the PBDA Specification in the “Resources” section later in this paper.

Dynamic Selection of Scanning TypeIn Windows Media Center, Microsoft® DirectShow® graphs are built by the Windows Media Center Receiver Service (Ehrecvr.exe) for all BDA and PBDA tuners during live TV setup. For any tuner that successfully completes live TV setup, the graphs are automatically built when the Media Center Receiver Service restarts.

When FRUN or periodic scan starts, Windows Media Center builds the tuner graph and then decides which type of scan to perform based on network type, tuning space, and the tuner’s services and methods. Figure 1 shows a simplified model of how Windows Media Center decides which type of scanning to use.



Figure 1. Dynamic selection of scan type

Exhaustive ScanningCompared to classic scanning, which relies on a fixed frequency list, exhaustive scanning allows far greater control on how the network is searched for transport streams.

A PBDA tuner can implement the PBDA Scanning Service to enable exhaustive scanning in Windows Media Center. This section explains the use of the Scanning Service APIs to scan the network by using the specific start and end frequencies. This section also explains how Windows Media Center interacts with the tuner to load the services by using all corresponding tuning information.

The PBDA Scanning Service is defined in the PBDA Specification, Part 1: Core Services. For more information, refer to the PBDA Specification in the “Resources” section later in this paper.

Configuring the PBDA Tuner for ScanningTo enable exhaustive scanning, the device must expose the tuning and scanning binding. For tuners that are based on the PBDA-IP or PBDA-KS specifications, bindings



are calling conventions for the tuner to transfer values from user mode to UPnP or into the kernel.

For a KS tuner, the PBDA tuning and scanning APIs are directed to the following kernel method sets: KSMETHODSETID_BdaScanning

KSMETHODSETID_BdaTuner

Each method set represents the calling entry into the device driver.

Starting with Windows 7, PBDA maps the scanning and tuning method sets to the BDA IScanningTunerEx, IScanningTuner, and ITuner COM interfaces. The implementation of these interfaces binds to PBDA-IP or PBDA-KS interfaces. These binding operations are defined in the following specifications:

PBDA Specification, Part 2: Binding for Bindings – IP – UPNP PBDA Specification, Part 2: Binding for Kernel Streaming

The following figure shows a DirectShow graph that represents the binding interfaces to a PBDA tuner or driver.

Figure 2. DirectShow graph of the PBDA binding interfaces for a tuner or driver

By using the PBDA scanning and tuning binding interface, Windows Media Center can scan a digital TV tuner that implements private frequency ranges that the PBDA device defines. Windows Media Center does not determine the start or end frequency, so the device can choose any suitable range.

The tuner device driver can implement its own scanning schema with one or more of the following: The driver can use a list of possible reception frequencies.



If the reception parameter cannot be automatically detected by the driver, the driver can use its own list of subparameter enumerations, such as modulation, symbol rate, or spectrum inversion.

The driver can scan the entire frequency range iteratively and detect all the necessary reception parameters in the most efficient way.

Iterative ScanningTuner and demodulator components can often report the next possible carrier frequency from the currently set frequency. You can use this information to approximate the transmission frequency by doing the following:1. The search algorithm moves forward in frequency steps until a carrier is detected

from the tuner. 2. Then, the algorithm determines the center of the carrier frequency by moving

backward and forward in fine steps until it reaches a frequency in the lock-in range.

Configuring the Tuner DeviceYou must configure the PBDA tuner appropriately for scanning. At a minimum, the General Purpose Name Value Service (GPNVS), Eventing Service, and Scanning Service must be implemented. Before it requests a scan, Windows Media Center calls the device for a system setup to set required parameters for the scanning task.

The following GPNVS values configure and define the PBDA tuner with the tuning capability:

PBDA:/Microsoft.com/NV/Variable/MCE/Source Types PBDA:/NV/Variable/Tuner Types

Windows Media Center uses the Source Types XML configuration to identify the device. For more information, see the PBDA Specification, Part 1: Profile – Microsoft, or other documents in the “Resources” section later in this paper.

The NetworkType ID attribute of the Source Types XML data must match the network IDs of the Tuner Types value. The network types that are defined by the Tuner Types represent the capability of the tuner. The BDA ITunerCap::get_SupportedNetworkTypes interface provides the supported network to the Microsoft network provider. This allows Windows Media Center to identify the supported network type of the tuner, as previously shown in Figure 2.

Note: For KS BDA drivers that are enhanced with PBDA, a classic BDA driver network is defined by the demodulator node type. After the driver exposes the PBDA method sets for scanning and tuning operations, the demodulator type is ignored.

The following example shows the Source Types XML data for a cable network DVB (DVB-C) scanning tuner.

<SourceTypes> <SourceType> <HeadendType id="PBDA DVB-C Test" name="DVB-C Test Tuner"/> <NetworkType



id="216C62DF-6D7F-4E9A-8571-05F14EDB766A" name="DVB-C Test"/> <VideoSource id="4CD4884F-3C04-4338-98DD-D400712EBB29" name="Cable"/> </SourceType></SourceTypes>Source Types XML for a DVB-C scanning tuner

After a device is configured as a scanning tuner, it provides the ability to move from one transport stream to another during scanning. Every time that the tuner signal locks during the scan run and outputs a transport stream, Windows Media Center can load the services and schedule guide data.

Note that an implemented PBDA GDDS is prioritized against exhaustive scanning. Alternatively, it is also possible to return the NetworkType ID value used in the GDDS call to GetGuideDataType() to use exhaustive scanning instead of GDDS.

As explained earlier in this paper, the scanning tuner uses Windows Media Center built-in GLIDs. Therefore, the NetworkType ID must be one of the known and supported IDs. This may change in future versions of Windows.

The following NetworkType IDs are supported by Windows Media Center.

NetworkType IDATSC 0DAD2FDD-5FD7-11D3-8F50-00C04F7971E2Digital Cable 143827AB-F77B-498d-81CA-5A007AEC28BFDVB-T 216C62DF-6D7F-4E9A-8571-05F14EDB766ADVB-S FA4B375A-45B4-4D45-8440-263957B11623ISDB-T 95037F6F-3AC7-4452-B6C4-45A9CE9292A2ISDB-S B0A4E6A0-6A1A-4B83-BB5B-903E1D90E6B6

Note: The NetworkType IDs shall be identical for tuners with GDDS. For a list of network types, see Section 5.7 in the PBDA Specification, Part 1: Core Services.

Scanning the Frequency Bandwidth by Using PBDAThe classic approach for scanning with an analog or digital tuner is to enumerate all possible reception parameters. Every time that an analog tuner detects a carrier signal, or a digital tuner identifies a signal lock with the demodulator, one or multiple services from a transport stream can be received.

A PBDA tuner must output a transport stream. PBDA with a Scanning Service allows the most flexible and optimized way to scan a network for transport streams, whereas processing logic for the transport stream itself is not necessary. The following are the advantages of using the Scanning Service:

Optimized tuning and demodulator use based on hardware capabilities. Short scanning time with full control over the tuner and demodulator timing.

Dedicated task that is decoupled from a tune request.

To determine the most efficient scanning approach, you must know the following hardware capabilities: Frequency lock-in range.



Demodulator auto-detection of transmission parameters such as modulation, forward error correction (FEC), and spectrum inversion.

If the frequency lock-in range is very small, such as 300 kilohertz (kHz), and no other mechanism is available to identify the next possible carrier, we recommend that you use a table of frequencies. Otherwise, an iterative stepping algorithm makes the scan task independent from divergent transmission frequencies and improves the total scan time.

The demodulator must run in all possible automatic detection modes, such as modulation, code rate, and spectrum inversion. Those parameters that cannot be automatically detected by the tuner, such as symbol rates, must be enumerated.

Figure 3 demonstrates the interaction of the PBDA Scanning Service in the tuner during a Windows Media Center exhaustive scanning task.

Figure 3. PBDA Scanning Service interaction during an exhaustive scanning task

The logical order of the scanning task is as follows:

1. StartScan() starts the search, and the device returns the SUCCESS_PENDING result.

2. The tuner searches until it reaches a signal lock.3. The tuner determines the signal statistics and signals the UpdateScanState()

event.4. GetTunerState() reads the current tuning parameters from the TunedXML

argument.5. ResumeScan() continues the search, and the tuner returns the

SUCCESS_PENDING result.6. GetScanState() reads the status periodically, and the scan stops with an error if

ulSecondsLeft is 0 or StopScan() terminates the scan.



After the scanning task starts with StartScan(), the tuner opens a thread that searches the available bandwidth until a signal lock is detected. Windows Media Center calls GetScanState() either periodically for the scan state or if the signal becomes locked. The following table describes the GetScanState() arguments.Argument name Data type NotesulSignalLock ULONG 0: no Lock , 1: LockedulSecondsLeft ULONG Estimated time until completion, in units of

secondsulCurrentFrequency ULONG Current carrier frequency, in units of kHz

The tuner must signal a newly detected signal with the UpdateScanState() event. After a signal is locked, the tuner must provide the diagnostic parameters through GetSignalDiagnostics(). The following table describes the GetSignalDiagnostics() arguments.Argument name Data type NotesulSignalLevel ULONG Signal strength, in units of dbµVulSignalLevelQuality ULONG Signal quality, in the range 0-100 percent

ulSignalNoiseRatio ULONG Signal to noise ratio, in units of dB

It is important to return signal quality values (0 to 100 percent) that differentiate identical transport streams transmitted at different frequencies. The following values are recommended to map into the quality range.

Signal quality Reception quality 0 No signal, transport stream, or high noise 1 - 20 Bad signal reception, transport with many errors but signal locked21 - 50 Weak signal reception, with interrupts and transport errors50 - 70 Signal reception valid, but with partial bit errors71 - 100 Good or very good signal

After the transport stream is analyzed for services or in-band guide information is retrieved, Windows Media Center calls ResumeScan() to continue the scan. The tuner then searches for the next available carrier in ascending frequency order. The tuner must update the internal scan state during the scan run.

Every time that a signal lock is detected Windows Media Center retrieves the state of the tuning by reading the TunedXML argument of GetTunerState(). From a KS-based tuner, the data is retrieved from the BDA_TUNER_TUNERSTATE structure. The XML structure includes all tuning parameters as defined in the PBDA Tuning Schema, such as the TuneRequest argument in a tuning space and the transmission parameters in the locator.

When Windows Media Center issues a tune request for a service within this transport stream, it uses the same TunedXML argument data but with information that is specific to services such as ServiceID or Program number. A call to SetTuner() starts this channel change. The tuner must make sure that the data returned in the TunedXML argument during the scan has all the necessary locator parameters to efficiently switch to the new transport stream at a different frequency.



The following example shows the data for a DVB-T network returned in the TunedXML argument.<tune:DVB OriginalNetworkID="-1" TransportStreamID="-1" ServiceID="-1"> <tune:TuningSpace xsi:type="tune:DVBTuningSpaceType" Name="DVB-T" NetworkType="{216C62DF-6D7F-4e9a-8571-05F14EDB766A}" SystemType="Terrestrial" NetworkID="-1"/> <tune:Locator xsi:type="tune:DVBTLocatorType" Frequency="576000" ModulationType="Uninitialized" InnerFECMethod="RS_204_188" InnerFECRate="2_3" OuterFECMethod="Uninitialized" SymbolRate="-1" Bandwidth="-1" LPInnerFECMethod="Uninitialized" LPInnerFECRate="Uninitialized" HierarchyAlpha="Uninitialized" GuardInterval="Uninitialized" TransmissionMode="Uninitialized" OtherFrequencyInUse="false"/></tune:DVB>Sample TunedXML argument data for a DVB-T network

Guide Data Delivery Service ScanningGDDS is a PBDA service that tuners implement. It works together with the PBDA Eventing Service. This service is defined in the PBDA Specification, Part 1: Core Services.

Windows Media Center can retrieve guide data in-band through the following methods: On demand. During FRUN or periodic scanning, Windows Media Center calls

GDDS::RequestGuideDataUpdate(), and then waits for an event from the tuner when services and schedule guide data is available.

When it signals events, the tuner should first signal the Event::ServiceInformationUpdated event, and then Event::GuideDataAvailable. After these events are signaled, Windows Media Center retrieves the services and schedule guide data and updates the electronic program guide (EPG) database.

On availability. If a tuner has some change in services or schedule guide data, it can signal a GDDS event to Windows Media Center. After the event is signaled, Windows Media Center can retrieve a list of services or a schedule based on the event type.



Communication ProtocolsTo provide in-band services or schedule, PBDA tuners must implement the following two PBDA services: GDDS

Eventing

This also assumes that other PBDA services, such as GPNVS and Tuning Services, are implemented and the DirectShow graph is successfully built.

When Windows Media Center calls GDDS::GetGuideDataType(), the tuner advertises its support for GDDS by returning the PBDA-SI GUID (C80C0DF3-6052-4c16-9F56-C44C21F73C45) in the DataType argument. Upon receiving this GUID, Windows Media Center prepares for GDDS scanning and calls GDDS::RequestGuideDataUpdate() to retrieve the guide data.

If GDDS::GetGuideDataType() does not return the PBDA-SI GUID, Windows Media Center checks whether it is a standard network-type GUID (such as DVB-T, DVB-S, ISDB-S, ISDB-T, or ATSC). If the GUID is a standard network-type GUID, Windows Media Center uses appropriate in-band scanning instead of GDDS scanning.

Note 1: If the tuner does not support GDDS scanning, the tuner's device driver must only support the GDDS::GetGuideDataType() API and must not return the PBDA-SI GUID. Because of this, the device driver does not need to support any other GDDS API.

Note 2: If GDDS::GetGuideDataType() returns an error, in-band scanning will not be started.

Before it calls this API in live TV setup or periodic scan, Windows Media Center makes sure that the tuner is not used for tuning or streaming. When this API is called, the tuner must take the necessary steps to download new guide data (services or schedule) before it signals GDDS events. The PBDA tuner’s method to acquire guide data is transparent to Windows Media Center.

If GDDS::RequestGuideDataUpdate() returns an error, Windows Media Center repeats the call every two minutes until it succeeds. If it succeeds, Windows Media Center waits for Event::ServiceInformationUpdated.

Note: Windows Media Center imposes a limit of 7.5 hours on GDDS scan, which means that if the scan is not successfully completed, Windows Media Center terminates the scan.

When Windows Media Center receives Event::ServiceInformationUpdated, it does the following:1. Windows Media Center retrieves services and their tuning information

(TuneXML). It first calls GDDS::GetServices() to get a list of services. Each service is identified by a 64-bit integer value (ServiceIdx).

For each ServiceIdx, Windows Media Center then retrieves the corresponding TuneXML data by calling GDDS::GetTuneXmlFromServiceIdx().



2. For each TuneXML data set, Windows Media Center calls GDDS::GetServiceInfoFromTuneXml() to retrieve the service description XML data. This data is returned through the ServiceDescription argument.

For each service, Windows Media Center saves the service Information and TuneXML data in the Electronic Program Guide (EPG) database.

3. After it processes services, Windows Media Center waits for the tuner to signal Event::GuideDataAvailable. When the event is signaled, Windows Media Center calls GDDS::GetGuideData() repeatedly to retrieve the Event Information Table (EIT) and updates the EPG database, until GDDS::GetGuideData() returns an error.

If a tuner has only in-band services (and no schedule guide data), it must return ERROR_NOT_IMPLEMENTED for the GDDS::GetGuideData() call. In this case, Windows Media Center completes the scan after it retrieves services instead of waiting for schedule guide data.

Windows Media Center waits for GDDS::GetGuideData() to return ERROR_NO_MORE_DATA with the GuideDataPercentageProgress argument set to 100. This indicates that all guide data was received. If GetGuideData() returns ERROR_NO_MORE_DATA but GuideDataPercentageProgress is less than 100, Windows Media Center waits again for Event::GuideDataAvailable to be signaled. If any other error occurs, Windows Media Center completes the scan. If all schedule guide data could not be retrieved and processed, Windows Media Center relies on a periodic GDDS scan to retrieve the remaining data.

During the scan, the tuner can signal Event::GuideDataError at any time to force Windows Media Center to end the scan. All guide data in the EPG database remains intact. No scan level database transaction is involved. Each service or event data update is one transaction. Scanning should be ended only by the tuner if it encounters a serious error. You should be aware that, depending on when the scan is ended, some services or schedule guide data may already be retrieved and stored in the EPG database.

Automatic Merging of Services and Schedule Guide DataWindows Media Center retrieves services and schedule guide data from the tuner and stores them in the EPG database.

If the tuner supplies SourceType XML data with a HeadEndType element for which a corresponding downloaded guide lineup exists, Windows Media Center merges services and schedule guide data from GDDS with the downloaded guide information. This merged lineup can also carry services from other tuners in the system.

Services and schedule merging occurs every time that either the downloaded guide or the GDDS-delivered guide information is updated.

Download Guide Lineup on HeadendThe tuner provides the SourceType XML data through the GPNVS variable (PBDA:/Microsoft.com/NV/Variable/MCE/Source Types). Based on the HeadendType element, Windows Media Center downloads the lineup (which is called the download guide lineup) from the online guide servers for the configured region in FRUN.



All tuners that provide the same SourceType XML data share the same guide lineup. This lineup contains services and schedule guide data, which is ultimately merged with the tuner’s scanned lineup services or schedule guide data.

The following example shows the HeadEndType element with a value of “TERd”.<SourceTypes> <SourceType> <HeadendType id="TERd" name="Digital Antenna (ChannelId PBDA Test)"/> <NetworkType id="74CF4BDF-C3AD-4c78-8845-76EB942AFE0E" name="74CF4BDF-C3AD-4c78-8845-76EB942AFE0E"/> <VideoSource id="31B740FC-499B-43c7-9562-6D04F85B7FD8" name="PBDA Channel ID Test"/> </SourceType></SourceTypes>Source Types XML for HeadendType

Periodic ScanningTuners retrieve current in-band guide data when either FRUN or periodic scanning begins. Windows Media Center uses periodic scanning to download the in-band guide daily. If a tuner is being used when periodic scanning is scheduled to start, Windows Media Center postpones the scan until the tuner is available. Windows Media Center performs a periodic scan every five minutes for a duration of 30 minutes. If it still fails, then Windows Media Center repeats the process every six hours until it succeeds.

Note: Windows Media Center never automatically stops streaming live TV or recording during any scan, unless users consent in a man-machine interface (MMI) dialog box that the tuner sends.

In-Band GuideThe tuner should update guide data when it is idle, regardless of when Windows Media Center is scheduled to start periodic scanning. This is necessary in the following two cases: If Windows Media Center is automatically configured during TV setup, only one

tuner from multiple tuners of the same SourceType XML data is used for scanning. In this case, Windows Media Center does not scan other tuners every day.

All tuners should have the same list of services, tuning data, and entitlement tokens because the TuneXML data retrieved from one tuner can be sent to another tuner that shares the same SourceType XML data. Therefore, all GDDS-capable tuners that share the same SourceType data must have the latest services and schedule.

Note: If multiple tuners of the same SourceType XML data are manually configured during FRUN, Windows Media Center uses all of these tuners for scanning.



A single tuner that must tune to a channel to download its guide data should use idle time for guide data updates because periodic scanning does not start when a tuner is streaming. For example, in a dual-tuner scenario, periodic scanning is done on Tuner A and not Tuner B. Tuner B might not be aware of a new service that Tuner A is aware of, which causes the new service to fail on Tuner B.

When a tuner downloads guide data that includes services or schedule changes, it should not wait for periodic scanning to start to update the Windows Media Center EPG database. It can continue to signal Event::ServiceInformationUpdated or Event::GuideDataAvailable until Windows Media Center retrieves the services or schedule. This method ensures that Windows Media Center updates the EPG database on a timely basis.

Services and EventsIn GDDS, services are identified by a 64-bit unique integer (ServiceIdx). Tuners must not change the ServiceIdx of a service.

The EIT data that GDDS::GetGuideData() returns consists of a number of events and is specific to one service. Each event in an EIT is identified by a unique 32-bit integer (EventID). EventIDs are unique relative to the service to which they belong. For example, a program on channel “XYZ” should always have the same EventId, until the event time has passed. An absolute ID of an event in GDDS is based on IDX and EventID. Two events that have the same EventID but different IDX values are considered different events.

Merging Services Based on the MatchName Service AttributeWindows Media Center merges services that contain the same broadcast content based on the MatchName service attribute. This attribute should be defined for each service in the downloaded guide and scanned lineups. If it is not defined or if the tuner has no corresponding download guide lineup, Windows Media Center imports only in-band services and schedule data in a merged lineup.

MatchName is a string attribute and consists of one or more service-specific distinct identifiers, separated by the ‘|’ character. Services may have one or more MatchName attributes based on call sign or channel number. The following are examples of possible MatchName values:

1. XYZ2. 100

3. XYZ:1004. XYZ:100| XYZ

5. XYZ:100:HD| XYZ:100| XYZ

In the first example, the MatchName value is simply one call sign. The second example demonstrates a channel number that is based on the MatchName value. The third MatchName value is based on call sign and channel number, both separated with ':'.

The fourth example has two MatchNames, separated with a '|' character. As examples 4 and 5 show, tuners should provide a more specific MatchName on the



left-most portion of the string, and then add a less specific MatchName on the right-hand portion.

In the corresponding download guide lineup, services can have an identical MatchName.

When Windows Media Center merges services, it chooses a service from the scanned lineup, and then it compares the service's MatchName values with all services in the downloaded guide lineup. A MatchName that contains multiple values (and is delimited by using the '|' separator) is compared from left to right until a match is found. The matching algorithm used by Windows Media Center is case-sensitive.

When any MatchName value matches, the services are merged. Tuning information for a merged service is always taken from the in-band service.

The following is an example of the TuneXML data for a service that contains a MatchName value.<?xml version="1.0" encoding="utf-8"?> <ps:Service xmlns:ps="http://schemas.microsoft.com/2006/ eHome/MediaCenter/PBDAService.xsd" name="XYZ" callSign="XYZ" ppv="false" subscribed="true" codec="H.264" channel="10" matchname="XYZ:100:HD|XYZ:100|XYZ"></ps:Service>TuneXML data that contains a MatchName value



The following figure illustrates how Windows Media Center merges services by using the MatchName value from the previous TuneXML data:

Figure 4: Merging In-band and download guide services based on MatchName value

Services and Schedule Updates and VersioningVersioning is not available for services, nor is it possible to update or add only one service. Every time that one or more services change, the tuner updates all services by first signaling Event::ServiceInformationUpdated and then supplying all services, as described earlier in this document.

Versioning is available on EIT, however, and Windows Media Center retains a cache of EIT versions. As a result, an EIT is discarded if its absolute ID (ServiceIdx + EventID) has been seen before with the same version.

EIT Present/Following UpdatesWhile tuned to a channel, a tuner can supply EIT present/following (p/f) data by first signaling Event::GuideDataAvailable and then supplying the EIT through GDDS::GetGuideData(). For p/f data, Windows Media Center ignores the value of the GuideDataPercentageProgress argument.

MMI Messages for the GuideA tuner can optionally send MMI messages to inform users of the status of the guide data. The tuner should do this only if the status is relevant to the user experience.



The methods for displaying MMI messages to users are outside the scope of this paper. For more information about these methods, refer to the PBDA Specification in the “Resources” section later in this paper.

Note: For displaying MMI messages, the tuner must implement the PBDA CAS and Eventing Service.

GDDS Usage Scenarios and ExamplesPBDA tuners can use GDDS in the following ways: A tuner that implements only GDDS::GetGuideDataType() can return the GUID

for a legacy network-type, such as terrestrial DVB (DVB-T). All other GDDS APIs must return ERROR_NOT_IMPLEMENTED.

For example, this method can be used by nonstandard network-type–based tuners to supply DVB-T services and EITs.

A tuner that supplies only services must return ERROR_NOT_IMPLEMENTED in GDDS::GetGuideData(). GDDS-based tuners can do this to supply only in-band services and rely on downloaded guide for the schedule guide data.

A tuner that supplies services and a schedule must implement all GDDS APIs. GDDS-based tuners can do this to supply both services and schedule from the in-band side.

The following sections provide examples in which in-band guide data is delivered through GDDS.

Example 1: GDDS In-band Guide Delivery for a DVB-C NetworkThis section provides an example on how GDDS-based tuners can provide in-band guide data to Windows Media Center. This example describes the steps involved when a tuner provides Windows Media Center with guide data for the DVB-C network type. This example follows the sequence of events discussed in “Communication Protocols” earlier in this paper.

Defining the DVB-C Tuning Space in the RegistryFor the DVB-C network type, the system-defined DVB-C tuning space must be defined in the system registry before it can be used by Windows Media Center with the DVBTuneRequest and DVBCLocator objects of the Microsoft Unified Tuning Model. For more information about this model, see the “Resources” section later in this paper.

System-defined tuning spaces are located in the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\TV\Tuning Spaces

The DVB-C system tuning space in this example can be created by using the following registry key.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\TV\Tuning Spaces\DVB-C] @="{C6B14B32-76AA-4A86-A7AC-5C79AAF58DA7}" "Name"="DVB-C" "Description"="Local DVB-C Digital Cable" "Network Type"="{DC0C0FE7-0485-4266-B93F-68FBF80ED834}" "System Type"=dword:00000000



"Network ID"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\TV\Tuning Spaces\DVB-C\Default Locator] @="{C531D9FD-9685-4028-8B68-6E1232079F1E}" "Frequency"=dword:ffffffff "ModulationType"=dword:ffffffff "InnerFECMethod"=dword:ffffffff "InnerFECRate"=dword:ffffffff "OuterFECMethod"=dword:ffffffff "OuterFECRate"=dword:ffffffff "SymbolRate"=dword:ffffffff

Providing Windows Media Center with Guide Data for the DVB-C Network TypeIn this example, the tuner provides guide data for the TV channel with the name “World News”. This channel is located on the DVB-C transponder at 482 kHz and can be demultiplexed with the following DVB triplet of original network ID (ONID): transport stream ID (TSID): service ID (SID).

ONID:TSID:SID = 0x233A:0x6000:0x6440

This triplet value has a decimal value of 38733625713728, and is used to reference the TuneXML and service data for the channel from the tuner.

When Windows Media Center calls GDDS::GetServices(), the tuner returns the following ServiceIdx value for the guide data of the “World News” channel.

<idxvalue="38733625713728"/>When Windows Media Center calls GDDS::GetTuneXmlFromServiceIdx() with the ServiceIdx argument set to 38733625713728, the tuner returns the following TuneXML data for the “World News” channel.

<tune:DVB OriginalNetworkID="9018" TransportStreamID="24576" ServiceID="25664"> <tune:TuningSpace xsi:type="tune:DVBTuningSpaceType" Name="DVB-C" SystemType="Cable" NetworkType="{DC0C0FE7-0485-4266-B93F-68FBF80ED834}"/> <tune:Locator xsi:type="tune:DVBCLocatorType" Frequency="482000" ModulationType="64QAM" InnerFECMethod="RS_204_188" InnerFECRate="2_3" OuterFECMethod="Uninitialized" OuterFECRate="Uninitialized" SymbolRate="6900000"/> <tune:Components xsi:type="tune:ComponentsType"/></tune:DVB>When Windows Media Center calls GDDS:GetServiceInfoFromTuneXml() with the TuneXml argument set to the TuneXML data of the “World News” channel, the tuner returns the following service information for the channel.



<ps:Service xmlns:ps= http://schemas.microsoft.com/2006/eHome/MediaCenter/PBDAService.xsd id="World News" name="World News" matchname="World News" callSign="World News" affiliation="WORLD TV" ppv="true" subscribed ="true" codec="MPEG2" channel="12"></ps:Service>

Example 2: GDDS In-Band Guide Delivery by Using ChannelIDMany network types use channels as a list of virtual services that bind each service to a virtual channel ID. Different ChannelID values for each service define the tuning data. This section provides an example that shows how to define the virtual service and use the tuning parameters. In the Source Types XML data, the id and name attribute values of the NetworkType element must be a unique GUID value for each tuner that uses the same network. The following example shows sample Source Types XML data that specifies a NetworkType element with the id and name attributes set to a GUID value of {74CF4BDF-C3AD-4c78-8845-76EB942AFE0E}.

<SourceTypes> <SourceType> <HeadendType id="TERd" name="Digital Antenna (ChannelId PBDA Test)"/> <NetworkType id="74CF4BDF-C3AD-4c78-8845-76EB942AFE0E" name="74CF4BDF-C3AD-4c78-8845-76EB942AFE0E"/> <VideoSource id="31B740FC-499B-43c7-9562-6D04F85B7FD8" name="PBDA Channel ID Test"/> </SourceType></SourceTypes>Source Types XML for a tuner that supports virtual services

In this example the service within the transport stream is defined by a ProgramNumber (ServiceID) value. This value is a unique ISO 13818 identifier for each service in a multiservice transport stream.

In the TuneXML data, the NetworkType and Name attribute values of the TuningSpace element must use the GUID value that was defined for the id and name attributes of the NetworkType element in the Source Types XML data. The following example shows a sample TuneXML data that specifies a NetworkType attribute by using the GUID value of {74CF4BDF-C3AD-4c78-8845-76EB942AFE0E}.

<tune:ChannelID ChannelID="101"> <tune:TuningSpace xsi:type="tune:ChannelIDTuningSpaceType" Name="74CF4BDF-C3AD-4c78-8845-76EB942AFE0E" NetworkType="{74CF4BDF-C3AD-4c78-8845-76EB942AFE0E}"/> <tune:Locator



xsi:type="tune:ATSCLocatorType" Frequency="482000" PhysicalChannel="1" TransportStreamID="24576" ProgramNumber="25664"/> <tune:Components xsi:type="tune:ComponentsType"/></tune:ChannelID>TuneXml for a ChannelID in a private NetworkType

When it tunes to a service, Windows Media Center uses the TuneXML data when it calls SetTuner().

Conversion from DVB-SI EIT to PBDA-SI for GDDS DeliveryIf a dedicated source is unavailable to deliver the guide information and the transport stream has EIT information, the EIT data can be converted into a PBDA-Service Information (SI) format that Windows Media Center loads by using the GDDS APIs. For more information about this format, see the PBDA Specification, Part 1: SI.

Sample source code for a software tuner can be found in the Windows Driver Kit (WDK). The sample code is located under the src\swtuner\MergedDevice folder of the WDK. This sample converts the EIT sections into the PBDA specification SI section format and adds the descriptors.

The conversion includes the following: Time format conversion

Version hash Caching

Running status extension Real time and offline guide processing

Entitlement token insertion

The sample requires the tuner to be able to process and demultiplex a transport stream. This is because the EIT data sections must be extracted and reformatted into the PBDA specification SI format.

The insertion of an entitlement token is outside the scope of the broadcast EIT data. However, this insertion enables the receipt of the same token if a recording to a specific guide program entry is scheduled. For more information, see the PBDA Specification, Part 1: Core Services - CAS.

Troubleshooting Possible Issues During DevelopmentThe following table describes various problems that you may encounter during the development of in-band delivery methods in your tuner. The table also provides suggestions for troubleshooting the problem.

Problem Troubleshooting suggestionsGDDS::RequestGuideDataUpdate() continues to fail and Windows Media Center continues to retry. The scan page in live TV setup remains at 0 percent.

Investigate on the tuner side why it is failing.



Problem Troubleshooting suggestionsGDDS::RequestGuideDataUpdate() succeeds but no GDDS events are signaled. The scan page in live TV setup remains at 0 percent.

You should investigate on the tuner side to see why events are not signaled. If they are signaled, you should see whether they appear in network traces.

GDDS::RequestGuideDataUpdate() succeeds and shortly thereafter Event::ServiceInformationUpdated is signaled. Windows Media Center reads all services but continues to wait for Event::GuideDataAvailable, which does not arrive. The scan page remains at 30 percent.

Investigate on the tuner side why Event::GuideDataAvailable is not signaled and, if signaled, then whether it appears in network traces.

During loading of services or schedule, the tuner departs the network, the scan is stopped immediately, and the scan page shows 100 percent progress.

Investigate this issue by looking at network traces.

During the loading of services or schedule, Event::GuideDataError is signaled, the scan is ended, and the scan page shows 100 percent progress.

Investigate this issue by looking at network traces.

ResourcesFor the latest information about the Microsoft Windows family of operating systems, see the Windows website at http://www.microsoft.com/windows.

WHDC website:Home page

http://www.microsoft.com/whdc/default.mspx

Protected Broadcast Driver Architecture (PBDA) Specification (Version 1.3.1)http://www.microsoft.com/whdc/device/broadcast/PBDA/pbda_spec.mspx

MSDN website:Microsoft Unified Tuning Model

http://msdn.microsoft.com/en-us/library/ee663615(VS.85).aspx

Windows Driver Kit (WDK)http://msdn.microsoft.com/en-us/library/ff557573(VS.85).aspx


http://msdn.microsoft.com/en-us/library/ff557573(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ee663615(VS.85).aspx

http://www.microsoft.com/whdc/device/broadcast/PBDA/pbda_spec.mspx

http://www.microsoft.com/whdc/default.mspx

http://www.microsoft.com/windows


Appendix. Glossary and AcronymsTerm Meaning

Download guide lineup A guide lineup that is downloaded from online servers

DVB Digital Video Broadcasting

EIT Event Information Table

EIT p/f EIT Present/Following

EPG Electronic Program Guide

Event Schedule guide data for a specific show

FRUN First Run

GDDS Guide Data Delivery Service

GDDS scan The Windows Media Center loading of services and a schedule from a tuner by using GDDS

GLID Guide loader plug-ins for in-band data

KS Kernel Streaming

Lineup An entity in an EPG database that contains a channel listing

MMI Man-Machine Interface

MSD Media Sink Device

MTD Media Transform Device

PBDA Protected Broadcast Driver Architecture

Scan The Windows Media Center loading of services and a schedule from a tuner to an EPG database

Schedule Program information, events, and shows in a guide

ServiceIdx A 64-bit index value that is used to retrieve TuneXML data for a service

TuneXML XML data for a tune request; the XML data is based on the applicable PBDA profile that identifies what to tune to

XML Extensible Markup Language


Contentsdownload.microsoft.com/.../PBDA-Scanning.docx · Web viewThis is because the EIT data sections must be extracted and reformatted into the PBDA specification SI format. The

Documents