TransEdit v4.2.1.1 and ATSC

[daniel2]

Hello

 

I have problem with TransEdit v.4.2.1.1 and ATSC 8VSB WinTV-HVR 950Q tuner.

I don't see "Bandwidth" option anymore and I have error "Invalid or incomplete input".

 

For example, in TransEdit v3.9.8.0 I can choose "bandwidth" and no problem to add channel.

 

Please check attached screenshots for both versions.

 

I'm using Windows 10 x64.

 

Please suggest.

 

[Griga]

Confirmed. This is a bug in TransEdit 4.2.1.1. The ATSC bandwidth is always 6 MHz, so there is no need to enter it, but the internal processing in TransEdit is wrong.

 

Where do you receive ATSC? AFAIK it is only used in North America and South Korea.

[daniel2]

In North America

 

Update: I did ATSC.ini manually and got tuner LOCK with TransEdit v4.2.1.1

 

INI:

 

[SATTYPE]
1=6000
2=New ATSC

[DVB]
0=1
1=473000,6,|Channel 14

 

Edited June 20, 2018 by daniel2
mistype

[Griga]

@daniel2

 

Please check your PMs.

[daniel2]

I found more critical problem: TransEdit can't control tuner at all.

If I plug tuner and use only TransEdit, tuner doesn't lock.

Then I use my own program and make tune to lock 473 MHz channel (I use GraphEdit).

After that TransEdit also can lock 473 MHz. But if I ask to lock 600 MHz channel,

which doesn't exist at all, TransEdit still shows old me 473 MHz channel.

I'm sure that TransEdit doesn't send any TuneRequest to the tuner.

I checked 4.1.2.2 amd 3.9.8, both the same.

[Griga]

1 hour ago, daniel2 said:

I'm sure that TransEdit doesn't send any TuneRequest to the tuner.

 

It does. I've checked the program flow under debugger control by setting the tuner type of my Hauppauge DVB-T2 device to ATSC. However, it looks like the driver of your WinTV-HVR 950Q tuner ignores the tune request for some reason. Unfortunately other feedback that we got in the past about the WinTV-HVR 950Q tuner is not very promising:

 

https://www.dvbviewer.tv/forum/topic/55337-hauppauge-950q-not-scanning-frequencies/

https://www.dvbviewer.tv/forum/topic/55226-scanning-failure-for-atsc-channels-using-happauge-950q/

 

However, there are some things that you can try:

1. Any change with Settings -> Hardware -> Use internal Network Provider filter off? It  lets TransEdit use the MS Network Provider filter instead of its own built-in component.
2. Any change with Settings -> Hardware -> Use standard interface on? It lets TransEdit use the IATSCLocator interface instead of talking more directly to the driver via IBDA_FrequencyFilter (so that's as close as you can get to a BDA graph in GraphEdit).
3. Settings -> Hardware -> Stop stream while tuning may also be worth a try (= perform tuning while the BDA graph is in stopped state instead of running state).

Unfortunately we can't test ATSC here in Germany at all, so it all depends on user feedback. However, the latest report from a Korean user with a Hauppauge WinTV-dualHD ATSC device suggests that the DVBViewer BDA implementation for ATSC basically works.

 

[daniel2]

Use internal Network Provider filter On/Off - both are not working.

Stop stream while tuning  On/Off - both are not working.

Most interesting is Use standard interface On

I got error:

 

 

[daniel2]

I want to share how I tune 950q in my own program and it works:

 

Quote

 

locator = DS.BDA.ATSCLocator()
assert (DS.BDA.IATSCLocator.put_CarrierFrequency(locator, 471250) == 0)                # central carrier frequency is 473 MHz
assert (DS.BDA.IATSCChannelTuneRequest.put_Locator(tuneRequest, locator) == 0)

 

 

[Griga]

31 minutes ago, daniel2 said:

Most interesting is Use standard interface On

 

https://www.dvbviewer.tv/forum/topic/55337-hauppauge-950q-not-scanning-frequencies/?do=findComment&comment=415161

 

The log should reveal where it fails.

 

[daniel2]

Please find attached log

TransEdit_Test.txt

[Griga]

Quote

12:37:06.706 Failed to add and connect the tuner filter

 

WinTV HVR-950 BDA Tuner doesn't connect to the Microsoft ATSC Network Provider, so building the BDA filter graph fails and TransEdit doesn't get to the point where it can use the IATSCLocator interface.

 

I wonder if it is caused by the other tuner types that are exposed by the WinTV HVR-950 BDA Tuner (Analog and DVB-C). Same happens here if I set the tuner type of my Hauppauge DVB-T2 device to ATSC, because it doesn't really match.

 

[daniel2]

For 950Q I'm not using Microsoft ATSC Network Provider (old), but general Network Provider (new).

 

Edited June 21, 2018 by daniel2
append image

[Griga]

Does the old Microsoft ATSC Network Provider connect to the tuner filter in GraphEdit?

 

Somehow the new Universal Network Provider doesn't work in TransEdit. ITuner.put_TuningSpace and ITuner.put_TuneRequest both fail with E_INVALID_ARG though it works pretty well with the old Network Provider. I'm just trying to find out why.

 

By default TransEdit doesn't use all this Locator, TuningSpace and TuneRequest stuff, but communicates directly with the tuner filter via the IBDA_XXX interfaces (particularly IBDA_FrequencyFilter in case of ATSC), that are internally used by the MS Network Provider filter. This works much faster and less error-prone with almost all BDA drivers except the WinTV-HVR 950Q tuner

 

[daniel2]

No, old Microsoft ATSC Network Provider can't be connected to 950Q and gives error.

 

Please see my fully working graph for 950Q.

I also have my own C# program to build the same graph and that program also works good with 950Q.

 

[daniel2]

Maybe that help.

 

When you use general "Network Provider", you need to specify network type. I do following:

 

DS.BDA.IATSCTuningSpace.put__NetworkType(tuningSpace, CLSID_ATSCNetworkProvider)

 

 

full code:

    tuningSpace = DS.BDA.ATSCTuningSpace()
    DS.BDA.IATSCTuningSpace.put_UniqueName(tuningSpace, "ATSC TuningSpace")
    DS.BDA.IATSCTuningSpace.put_FriendlyName(tuningSpace, "ATSC TuningSpace")
    DS.BDA.IATSCTuningSpace.put__NetworkType(tuningSpace, CLSID_ATSCNetworkProvider)

    (hr, tuneRequest) = DS.BDA.IATSCTuningSpace.CreateTuneRequest(tuningSpace)

 

[Griga]

6 minutes ago, daniel2 said:

DS.BDA.IATSCTuningSpace.put__NetworkType(tuningSpace, CLSID_ATSCNetworkProvider)

 

I know. That's exactly what TransEdit does if it uses the MS Network Provider.

 

TransEdit and DVBViewer don't use the MPEG2 Demultiplexer and the other BDA filters that are connected to its output pins at all. They are replaced by a simple dump filter that receives the TS output of the Capture/Receiver component for further processing. By default the MS Network Provider Filter is replaced by our own NP. It is more or less a dummy filter because there is nothing to do for it when the IBDA_XXX interfaces are used. You can have a look at it with "Connect to Remote Graph" in GraphEdit (provided the BDA graph can be built - rather use the Analyzer function for it, not scanning a single frequency).

 

Maybe the WinTV-HVR 950Q tuner only wants to ccoperate with the MS Universal NP.... obviously it connects to the internal TransEdit NP, but without responding to IBDA_FrequencyFilter.put_Frequency.

 

I have to do some other things now, but will come back to this topic...

 

[daniel2]

Yes, I agree. 950Q wants to cooperate only with Universal NP, and Universal Network Provider doesn't tune if there is no BDA MPEG-2 Transport Information Filter.

It's strange but it's true. You need TIF to make TuneRequest gives effect.

 

I hope you will prepare test version soon, I'm really interesting to get 950Q working with TransEdit.

[daniel2]

https://msdn.microsoft.com/en-us/library/windows/desktop/dd693014(v=vs.85).aspx

 

Quote

 

Remarks

The Network Provider acts as the default tuner in a BDA filter graph, by exposing the ITuner interface. No signals or data actually pass through this filter. It works closely with the Transport Information Filter (TIF) and the MPEG-2 Demultiplexer to acquire transport streams and route the elementary stream to the appropriate downstream filters.

 

 

 

 

[Griga]

I made some progress concerning the Universal NP,  but without getting to a solution.

 

DVBViewer and TransEdit can't work with a standard BDA graph as intended by MS. On the one hand it is too bloated, on the other hand too limited for what we want to do. So in order to make the MS NP work we tried to make our BDA dump filter a TIF replacement,  allowing to register it with IBDA_TIF_REGISTRATION.RegisterTIFEx. This is extremely difficult because the NP expects some special TIF interfaces including undocumented ones (read more about it here). Unfortunately MSDN doesn't support writing a TIF replacement at all.

 

Finally we managed to deceive the old tuner type-specific MS NPs by implementing some dummy interfaces in the BDA dump filter, so it is accepted as TIF and enables tuning. However, this doesn't work with the Universal NP. I guess it wants some more / other TIF interfaces, probably undocumented again.

 

So what I've achieved up to now: After the graph has been built with the Universal NP (using my Hauppauge DVB-T2 device) the whole tuning space / tune request / locator stuff is executed without error. But actually no tuning takes place. I always get the stream from the last frequency that has been tuned successfully, as reported by you here. This is most likely caused by TIF registration failing with E_INVALIDARG.

 

[daniel2]

I checked TransEdit's graph with GraphEdit remote connect.

 

When I use TransEdit with following settings:

 

I have following graph:

 

 

It's very close to what I have in my program.

 

 

What I suggest to try:

 

Universal Network Provider -> BDA Tuner -> BDA Capture -> Infinite Pin Tree Filter ({F8388A40-D5BB-11D0-BE5A-0080C706568E}) -> and then you can connect your current BDA Sample Dumper and to second pin you can connect MPEG-2 Demultiplexer  with BDA MPEG2 Transport Information Filter and MPEG-2 Sections and Tables

.

 

 

 

 

 

[Griga]

Do you just connect the filters or do you additionally configure the MPEG-2 Demultiplexer? Is IBDA_TIF_REGISTRATION.RegisterTIFEx performed automagically or do you have to call it explicitely?

 

Anyway, it's too much overhead for becoming a general solution in DVBViewer/TransEdit. Maybe it makes the WinTV-HVR 950Q work, but who knows what it will do with the other 400 devices in our hardware database...

 

I 'm still wondering why setting up the frequency with IBDA_FrequencyFilter doesn't work. In the end the Universal NP can't do much more than that. TransEdit does the following:

• call IBDA_DeviceControl.StartChanges on all device filters (tuner, receiver/capture) that expose this interface.
• call IBDA_AutoDemodulate.put_AutoDemodulate on all device filter control nodes that expose this interface (I found this as recommendation somewhere, dunno if it is really necessary for ATSC... DVBViewer doesn't do it)
• call IBDA_FrequencyFilter.put_Frequency(Frequency - 1750)  and IBDA_FrequencyFilter.put_Bandwidth(6) on the first device filter control node that exposes this interface and where both calls succeed (maybe it should rather be called on all control nodes because it is a hybrid tuner?)
• call IBDA_DeviceControl.CheckChanges and IBDA_DeviceControl.CommitChanges on all filters that expose this interface.

The control nodes are retrieved by querying the device filters for IBDA_Topology, calling IBDA_Topology.GetNodeTypes and IBDA_Topology.GetControlNode for each list entry.

 

[Griga]

The following document explains why the old NP filters don't connect to the WinTV-HVR 950Q tuner:

 

http://www.silicondust.com/hdhomerun/hdhomerun_development.pdf

 

see BDA Demodulator type section. The TransEdit_Test log shows that two demodulator nodes are published: KSNODE_BDA_8VSB_DEMODULATOR = {71985F4F-1CA1-11D3-9CC8-00C04F7971E0} and KSNODE_BDA_QAM_DEMODULATOR = {71985F4D-1CA1-11D3-9CC8-00C04F7971E0}.

[daniel2]

Yes, I just connect the filters and don't configure nothing.

I see that you do a lot of internal work to confiure the tuner. For me it's more simple, I only append filters and send one TuneRequest.

 

950Q can work in two modes ATSC and Cable QAM. I expect that if i set ATSC in TransEdit settings, you will tune 950Q as ATSC and not as cable QAM.

[Griga]

Do you have the Signal Monitor tool from Hauppauge mentioned here?

 

Quote

I found it helpful to use a Happauge device since it comes with a program called Signal Monitor which displays whether the tuner is in ATSC or QAM mode.

 

[daniel2]

Yes, I have

 

TransEdit correctly sets 8-VSB mode

[daniel2]

I checked my GraphEdit.

If I have TIF, then the Tuner changes carrier frequency correctly.

If I remove TIF, the Tuner works on last loaded frequency and doesn't change carrier frequency anymore.

 

TIF is 100% necessary when I work with Universal Network Provider.

[Griga]

29 minutes ago, daniel2 said:

TransEdit correctly sets 8-VSB mode

 

TransEdit does nothing about it, except calling  IBDA_AutoDemodulate.put_AutoDemodulate (standard interface off only), and hoping that the driver will sort it out somehow. I guess 8-VSB mode is the default. Here is something from Hauppauge about this topic:

 

http://webcache.googleusercontent.com/search?q=cache:DwzEKOYGS1EJ:pastebin.ca/raw/921178

 

(see "Driver Extensions for QAM/ATSC Tuning" section).

 

[daniel2]

Let me revise what we have now:

(1) TransEdit had problem with ATSC Channel GUI editor, you fixed that.

(2) TransEdit shows error when we use "Standard Interface" with 950Q - it's ok, because ATSC Network Provider is too old and we should not use it at all.

(3) With Internal Network Provider we have problem that tuner doesn't react on carrier frequency changes, but other features work correct, I can see packets and analyze them with TransEdit. You said it's because 950Q speciality. It's ok for me, I don't want you to change your Internal Network Provider.

(4) When we disable "Internal Network Provider", GraphEdit uses "Universal Network Provider" and builds graph very close to what I have in my GraphEdit.

And I found that without TIF, my graph also doesn't tune carrier frequency. Looks like TIF is necessary for 950Q.

I ask you to add TIF to your graph when you have "Universal Network Provider" and let me check how it works.

 

[Griga]

On 6/23/2018 at 1:20 PM, daniel2 said:

What I suggest to try:

 

Universal Network Provider -> BDA Tuner -> BDA Capture -> Infinite Pin Tree Filter ({F8388A40-D5BB-11D0-BE5A-0080C706568E}) -> and then you can connect your current BDA Sample Dumper and to second pin you can connect MPEG-2 Demultiplexer  with BDA MPEG2 Transport Information Filter and MPEG-2 Sections and Tables 

 

Doh! The MPEG2 Demux creates 30 output pins here. Looks like a hedgehog... or a resource hog. I'm not really fond of hogs. However, it may be useful for experimental purpose if the code can easily be plugged in and out. That needs some restructuring of the graph building code.

 

2 hours ago, daniel2 said:

(3) With Internal Network Provider we have problem that tuner doesn't react on carrier frequency changes

 

That's what I would like to fix. Maybe we can get some information from Hauppauge...

 

[daniel2]

I'm ready to help you to debug your version with Internal Network Provider, but I'm sure that Universal Network Provider should work, because I use it.

Maybe 950Q driver is incompatible with your Internal Netowrk Provider. In truth, it's not so important for me as to work with Universal Network Provider.

[Griga]

3 hours ago, daniel2 said:

Maybe 950Q driver is incompatible with your Internal Netowrk Provider.

 

Basically the NP does two things:

1. Configuring device filters when they get connected and call IBDA_NetworkProvider.RegisterDeviceFilter, particularly by querying the filter for the IBDA_Topology interface and using methods like CreatePin and CreateTopology. This is also performed by the internal TransEdit NP.
2. Providing an abstraction layer above the device filter properties (all that tuning space, locator etc. stuff) by translating tune requests to IBDA_XXX calls. This can be done as well without the NP by using the IBDA_XXX or IKSPropertySet interfaces of filters directly (which is inevitable if device filters provide properties that are not used by the NP or not covered by the BDA standard - see Hauppauge driver extensions link above).

So in theory calling the same BDA_XXX methods with the same parameters as the NP does in 2 should yield the same tuning result. I think we can use the method proposed by you for logging which IBDA_FrequencyFilter and IBDA_DigitalDemodulator values are set after the tune request, plus logging which IBDA_NetworkProvider methods are called. Maybe that reveals something...

 

[daniel2]

I agree with you

[Griga]

12 hours ago, Griga said:

logging which IBDA_FrequencyFilter and IBDA_DigitalDemodulator values are set after the tune request

 

It seems that device filters tend to implement the setters without getters

 

Is there any point in your code where the 8VSB modulation comes in, e.g. in the default locator of your ATSC tuning space? I'm asking this because a device that also supports QAM, but without automatic modulation detection may require to set up the modulation for tuning. TransEdit doesn't do it.

 

As consequence TransEdit would have to provide a modulation column for ATSC in the transponder list editor.

 

[Griga]

Strange:

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\TV\Tuning Spaces\ATSC\Default Locator

 

contains ModulationType = 7 = BDA_MOD_128QAM. Same value in the ATSC Cable default locator. 

 

[daniel2]

No, I don't specify 8VSB in my code. I only make
 

Quote

tuningSpace = DS.BDA.ATSCTuningSpace()

DS.BDA.IATSCTuningSpace.put__NetworkType(tuningSpace, CLSID_ATSCNetworkProvider)

locator = DS.BDA.ATSCLocator()
assert (DS.BDA.IATSCLocator.put_CarrierFrequency(locator, 471250) == 0)
assert (DS.BDA.IATSCChannelTuneRequest.put_Locator(tuneRequest, locator) == 0)

 

 

[daniel2]

When I send TuneRequest to 950Q, the tuner starts to check in sequence: cable 64-QAM, cable 256-QAM, ATSC 8VSB, then again until one of them get lock.

I see that in Signal Monitor tool from Hauppauge in status field.

I think you don't have to define modulation type for 950Q.

[Griga]

Just to let everybody know the solution that we have finally found:

 

The ATSC 8VSB WinTV-HVR 950Q tuner wants the frequency to be specified in Hz, not in kHz as TransEdit and DVBViewer do. This does not comply with the Microsoft recommendations (see here), but can be solved by explicitely setting the frequency multiplier value to 1000 (instead of 1, which seems to be the driver default).

 

Future DVBViewer / Media Server / TransEdit releases will contain this fix. Thanks to @daniel2 for his help to solve this problem!

 

[daniel2]

Griga, thank you for your professional work!