With DVB-T, most of the time, specifying the frequency is enough to tune.
The tuner device automatically retrieves the other parameters (guard interval,
LP/HP streams FEC, transmission mode, etc) from the embedded Transmission
Parameter Signalling.

On a software standpoint, the application sets the frequency in the tuning request.
The other parameters, if set, are mostly ignored (they can be wrong, the tuning
is done anyway).

The question is: once the tuning is established and the TS received, how can the
actual tuning parameters be retrieved by the application?
How can the BDA driver pass this information back to the application?

ITuner::get_TuneRequest is useless for that: the returned request is the one that
was originally submitted by the application (with unset/incorrect parameters).

I see no other documented interface returning tuning parameters.
The BDA driver I currently use (Hauppauge Nova-T Stick DVB-T Tuner)
does not seem to expose any interface for that.

When scanning a network, determining the tuning parameters is sometimes
quite important, so this is a legitimate request.

The hardware tuner can do that: the same DVB-T tuner in a Linux PC does
return the actual tuning parameters (there is provision for this in the Linux DVB
API). How can you do this with Windows / BDA?

MS Quote:

Right, but my question is different.

The Terrestrial Delivery System Descriptor is a descriptor which is (or may be) inserted by the broadcaster in the NIT. There is absolutly no guarantee that its contents is correct. In a DVT-T network, it is quite possible that these descriptors are completely wrong. This is especially the case in France. In the NIT, these descriptors are identical for all TS with "template" values which do not reflect the reality: all frequencies are 0xFFFFFFFF, all constellations are 64-QAM, etc. In the reality, the frequencies are obviously different, some TS use 16-QAM, the FEC may be 3/4 or 2/3, etc.

So, the interface you suggest gives access to one (possibly incorrect) data structure which is in the TS. My need is to inquire the tuner hardware through the driver to get the actual demodulation parameters it uses.

I thought that the french were the fore bearers of DVB technology, especially in the Broadcast industry. Typical that they can't even get it correct in their own back yard.

How about using the "IBDA_DigitalDemodulator" interface on the tuner filter?

You are right for the industry. The national regulator is another matter...

The regulator has chosen not to create regional variants of the PSI/SI. Since there will be +/- one thousand different transmitters when the deployment is complete, often close to each other, with a heavily loaded existing frequency usage, with 8 neighbour countries with their own frequency plans, they have decided that this would be too complicated. I do not mean it was the right decision, it was just the political decision of the regulator. As a consequence, the same NIT is broadcast on all TS from all transmitters in the country.

Moreover, the regulator recently realized that because of some thousands of legacy rubbish chinese STB, this NIT must fit on one single section. Then, you will see the mess...


Because this interface does simply NOT return DVB-T parameters: guard interval, transmission mode, etc....
Here is the list of its "get" methods:

get_InnerFECMethod
get_InnerFECRate
get_ModulationType
get_OuterFECMethod
get_OuterFECRate
get_SpectralInversion
get_SymbolRate

Nothing else...

Yes, it's easy for us here since we only have six networks, mind you it's taken 8 years to get usable EIT data.
Then I guess it comes down to the fact that the DVB_T BDA tuner filter should update the TuneRequest or the IDVBTLocator Interface when it has locked to the transmission. The most likely reason for the missing info is because of ignorance since I can't see anywhere in documentation that it is a requirement for the DVB-T tuner device filter to update the NP's tunerequest.

Well, I do not see any requirement for that. After all, "get tune request" means "what did I request?", it is not "get tune result".

DirectShow is a huge framework with zillions of features but the most basic & simple features are simply missing. Typical Microsoft approach... In the Linux DVB framework, which is infinitely simpler, each driver is committed to return its current parameters. Instead of providing dozens of different partial and / or optional interfaces which are used in an anarchic way by the various drivers, there is just one simple ioctl which returns everything.

Thinking twice, I realize that getting tuning parameters on Windows is simply impossible. None of the specialized interfaces which are exposed by the tuner filter return such info. As a last resort, I tried IKsPropertySet interface on the tuner filter, its input and output pins, all its internal nodes (accessed through IBDA_Topology). Only the input pin supports some tuning-related properties:

Category KSPROPSETID_BdaSignalStats, properties ("get" only obviously):
KSPROPERTY_BDA_SIGNAL_STRENGTH
KSPROPERTY_BDA_SIGNAL_QUALITY
KSPROPERTY_BDA_SIGNAL_PRESENT
KSPROPERTY_BDA_SIGNAL_LOCKED
KSPROPERTY_BDA_SAMPLE_TIME

Category KSPROPSETID_BdaFrequencyFilter, properties ("set" only, no "get" supported):
KSPROPERTY_BDA_RF_TUNER_FREQUENCY
KSPROPERTY_BDA_RF_TUNER_BANDWIDTH
KSPROPERTY_BDA_RF_TUNER_FREQUENCY_MULTIPLIER

Nothing else.

Specifically, the category KSPROPSETID_BdaDigitalDemodulator is not supported at all. Too bad since it defines interesting properties like KSPROPERTY_BDA_GUARD_INTERVAL or KSPROPERTY_BDA_TRANSMISSION_MODE. It is particularly frustrating that Microsoft provides a category named "KSPROPSETID_BdaDigitalDemodulator" and an interface named "IBDA_DigitalDemodulator" which do not expose the same properties.

So, since ITuner::get_TuneRequest is provided by the network provided filter (Microsoft provided) and not the tuner filter, I see no possible way for get_TuneRequest to return the actual parameters since the tuner filter does not provide them.

I've not tried to do what you are attempting, but I think you are on the right lines in usning interfaces exposed by individual nodes internal to the tuner topology. It looks to me that IBDA_DigitalDemodulator would get you the info that you want. However, from my observation of a (very) small selection of DVB-T tuners this isn't always exposed.

For example, here's what I see for a Hauppauge Nova-T PCI card:



And here's what I see for a Creative Labs DVB-T USB tuner (which uses DiBcom chipset):



So, it looks to me that you could get the demodulator info from the Nova-T but not from the Creative tuner. If my reading of the DirectShow docs is correct then exposure of the IBDA_AutoDemodulate interface is to be preferred over IBDA_DigitalDemodulator since it means that the Network Provider doesn't have to bother with these parameters when tuning. However, interestingly, my little tuner topology discovery program shows that a QueryInterface fails on the auto demodulate interface. I can't explain that. But likewise, the Nova-T seems to expose two interfaces (I guess private to Hauppauge since I haven't been able to identify the GUIDs) that also fail a QI.

Changing the subject back to the content of the earlier part of this thread, I found the decision on the NIT content in France to be interesting. I would have thought that we have a similar level of transmitter and network complexity here in the UK as in France. But, AFAIK, the NIT contents are specific to each transmitter in the network. We also have a proliferation of cheap Chinese sourced STBs (and an awful lot of PVRs that come from Turkey) but they seem to cope quite well and in a standardised way with the information provided by the network. I'm sure that the Freeview organisation and logo/branding they do plays a part in this (although I'm not sure that consumers make buying decisions based on the presence/absence of such logos).

Pete

Out of interest, I just examined the TS coming in from my local transmitter (Crystal Palace in London). The NIT does all fit in one section although there isn't a great deal of room to spare since the length is around 900 bytes. But within those 900 bytes we get full data on 88 services carried by six multiplexes.

Pete

This is because the UK DTTV has made the very good decision to be fully DVB-compliant. Each transmitter broadcasts only the relevant PSI/SI for what is emitted from this transmitter. All over the country, each service is uniquely identified by its DVB triplet original netw id / ts id / service id. Since in 1998 the UK DTTV was the very first operational digital terrestrial TV network in the world, this is even more remarquable.

This is why each NIT can fit into one section in UK. In France, without regional PSI/SI, the NIT is supposed to describe all services in the country, including more than 100 regional variants and programs. The current NIT, if complete, could clearly not fit into one single section. This is what happened in september 2007, the new "national NIT" started to use 2 sections, resulting in thousands of furious owners of cheap STB who could no longer detect any channel. Within one week, in order to get back to a one-section NIT, the national regulator had to define a new strategy where distinct regional variants had to use the same DVB triplet, provided that their respective regions were geographically distant enough... Holy DVB, please forgive them for their sins !

In France, as always, everything is political. The private commercial analogue TV operators are run by influent businessmen, close friends of the previous and current governements, and they feared the competition of the new DTTV channels in the advertising market (which was right if you read today's figures about the TV advertising market). As a result, there was a clear sabotage of the French DTTV. Stupid technical decisions were made to slow down the start and rise of DTTV. Apart from badly designed PSI/SI, other stupid decisions included the use of MPEG-2 for FTA services and MPEG-4 for pay-TV. At the time of this decision, MPEG-4 STB were not ready and this was another good reason to delay DTTV. Smart isn't it?

Well, you still cannot get the demodulator info from the Nova-T since, as I mentioned in a previous post, IBDA_DigitalDemodulator is so generic that it does not return the DVB-T parameters.

Only IKsPropertySet with category KSPROPSETID_BdaDigitalDemodulator could do that. But Nova-T does not expose IKsPropertySet.

Thanks for the interesting description of the situation in France. I wonder what would happen in the UK if our NIT ever strayed over into a second section. Would we get loads of STB failures? So far, the multiplexes used for DVB-T HD trials that we've had in the UK have been treated as a separate network with their own NIT (and EPG). But if/when we get a proper national HD network that is integrated with the current SD network then our transmitters would surely need to carry a NIT that is longer than one section. Of course they might choose not to integrate HD and SD into one network which would avoid the problem.



Comparing the DirectShow documentation for IBDA_DigitalDemodulator with the WDK docs on KSPROPSETID_BdaDigitalDemodulator it would appear that there is a 1:1 match for many of the parameters. So you could get FEC info, modulation type, spectral inversion and symbol rate. Provided that is, of course, that Get methods are supported for these properties (something not necessarily guaranteed). But you are right that IBDA_DigitalDemodulator is incomplete since for some reason it doesn't include the guard interval or transmission mode parameters. And looking at the WDK headers, there are two more parameters (roll-off and pilot) that are present in the property set. These are not even mentioned in the WDK docs.

So, the conclusion seems to be that on some tuners you could get some parameters. But if you want a general solution that would work for all parameters on any tuner then, with the BDA architecture as currently defined, you're out of luck.

Pete

From Windows SDK v6.0A:

In bdaiface.h, the get methods for IBDA_DigitalDemodulator are:

get_ModulationType
get_InnerFECMethod
get_InnerFECRate
get_OuterFECMethod
get_OuterFECRate
get_SymbolRate
get_SpectralInversion

In bdamedia.h, the property list of KSPROPSETID_BdaDigitalDemodulator is:

KSPROPERTY_BDA_MODULATION_TYPE
KSPROPERTY_BDA_INNER_FEC_TYPE
KSPROPERTY_BDA_INNER_FEC_RATE
KSPROPERTY_BDA_OUTER_FEC_TYPE
KSPROPERTY_BDA_OUTER_FEC_RATE
KSPROPERTY_BDA_SYMBOL_RATE
KSPROPERTY_BDA_SPECTRAL_INVERSION
KSPROPERTY_BDA_GUARD_INTERVAL
KSPROPERTY_BDA_TRANSMISSION_MODE
KSPROPERTY_BDA_ROLL_OFF
KSPROPERTY_BDA_PILOT

So, the interface is missing access to the last 4 properties.

Picking up on the previous discussion on multi-part NIT usage, it appears that in the UK some transmitters are starting to broadcast a multi-section NIT and that it is causing problems with a minority of STBs.

More info here:

http://www.digitalspy.co.uk/forums/showthread.php?t=844007

and

http://www.digitalspy.co.uk/forums/showthread.php?t=832513

Pete