I'm looking for anyone who wants to write a program using the Microsoft TV Technologies interface. I've written a set of BDA drivers for the Twinhan card. This replaces Twinhan's drivers (and precludes the use of their SDK, WinDTV, capture.exe and any other software based on their SDK).

What does this mean? Instead of programming to a Twinhan-proprietary API, a developer programs to a Microsoft-proprietary API. Theoretically you gain the benefit of writing applications that don't have to be rewritten for other digital TV hardware as long as that hardware has BDA compliant drivers. Hence my effort to write BDA compliant drivers for the Twinhan DVB-t card.

Your application can be written in any of C#, C++, Visual Basic, or even scripted into an HTML page.

C# support is not complete in the current DirectX SDK - we'll be waiting on Microsoft to release a complete Managed DirectX sometime in the future. You can, however, get access to the Video Control by importing the COM/ActiveX object.

I would like to be involved in any C# project that someone may want to write. I don't mind C++ but I expect as far as Microsoft is concerned C# is the horse to back in future - let me know if I'm wrong here.

As my drivers are currently alpha quality I don't want to give them out to just anyone. I don't want to hear from whingers complaining that they don't work or that their computer crashed because of them. I only want to hear from the technically competent - not the technically deficient.

If you don't know much about this stuff but want to learn then start reading the docs at MSDN

http://msdn.microsoft.com/library/default....echnologies.asp

If you're ready to do some programming you should install the latest SDK
http://www.microsoft.com/downloads/details...&DisplayLang=en

Oh, by the way, this is only for Windows XP. Any older O/S may not have the required support and I certainly won't support them.

Spectrum

Spectrum,

Great initiative. If there is anything I can assist you with, please let me know.

Cheers

Renura

Spectrum, this is great news. The BDA is very important to develop a uniform standard. I know a lot of the other forums I have been reading, BDA support is something that ppl are looking forward to. I haven't done a lot of programming since I left uni, but I would love to be further involved in this project. I may do some more reading.....

BTW if you would like me to do some closed testing, I would be happy.....I have a lot of testing experience (My f/t job) and good programming/IT background.....

Let me know..

Andrew

I'm keen to have a go. I've already started writing a program that uses the SDK. I don't think it would be hard to incorperate a MSTV mode into <a href='http://robdvd.radfiles.net/viewtopic.php?p=3883#3883' target='_blank'>DigitalWatch</a>. I'm writing digitalwatch in c++ (no mfc) because managed directshow in c# isn't available yet, but i'm keeping it very OO so it's wouldn't be all that difficult to port it to C# later.

Before i started DigitalWatch i did into using MSTV Technology and there was one thing i wasn't sure about. If i understand correctly, the BDA MPEG-2 TIF filter parses the transport stream to get the PID's. Will it be able to parse AC3 streams correctly? I don't doubt that it'd detect the streams, but it'd probably just say that they're private streams. I'm wondering if we'll need to write a filter that we pass the audio stream through that will parse the stream for the correct type.

It doesn't pick up on AC3 streams by itself. I don't think the solution is to write a filter. Hopefully it's just a matter of telling the MPEG2 Demultiplexer which PID to map to the audio output pin. This is supposed to be done by telling the VideoControl which components to use:
http://msdn.microsoft.com/library/en-us/di...mcomponents.asp
The problem we may have is whether Australian AC3 streams are a recognised component type - I suspect not. We should be able to program around this if necessary - I need to learn more first.

One point I'd like to make. Tune requests will normally come from a "Guide Store" http://msdn.microsoft.com/library/en-us/di...deloverview.asp, this is a database of channels, programs, PIDs, component lists etc. It would be fantastic if any and all projects that are created around this effort could work with a single standard database schema. The more we can share the faster we can get a suite of apps working. I guess an MS Access format database would be the best choice as C#, C++, and Visual Basic have no difficulty reading from one.

The database will be updated from live information in the MPEG transport stream (eg. audio or video streams being moved to different PIDs by the TV Networks), and by guide information either adapted from XMLTV or slurped into a database driectly from a provider. Maybe as a rewrite of http://www.onlinetractorparts.com.au/rohbags/xmltvau/ that pulls the data from EBroadcast and puts it into the database. It is of course possible to write the guide interface to read XMLTV docs directly but I don't know wheter XMLTV docs can hold PID mapping data??? Anyway, we can thrash that out in time.

Spectrum

I suspect that Australian AC3 streams will simply be recognised as a private stream, so we're going to need to be able to parse the private streams to see what's in them.

The easiest way i can think to do this will be to map the private stream to a pin on the demux, and connect it to a parser filter that we'd have to write. Once the parser recognises the type then we can remove the parser and unmap the pin. If we do this for all the private streams we can then store the stream types. then when we want to play a stream we'll know the right MediaType and SubType for the pin we create on the demux.

It's a bit messy, but i can't think of a better way, unless we can create custom Component types. We'll have to look into it some more i think.

On a separate note, the BDA drivers make this card useable in Windows XP Media Center Edition 2004 http://www.microsoft.com/windowsxp/mediace...ter/default.asp

Unfortunately Microsoft don't support MCE in Australia :cry:

Hi Spectrum

I am keen to have a go too!

My experience is really with VB, VB.NET etc, so I'm not sure how much I can do with c++.

As for MS support of DirectShow as managed code, I would not be holding my breath.
"There are no current plans to implement a "Managed DirectShow" platform"
http://msdn.microsoft.com/library/default....rectshowfaq.asp

Cheers
Darren

Yer, i read that and that's why i've written in c++. I was originally thinking about putting the directshow stuff in a dll with a nice interface so i could do higher level stuff in c# but the more i do the less practical it seems.

Nate,

I was wondering if the DLL/COM approach was going to work or not. If it was done this way, one group could focus on the low level stuff and another could work on the UI and other interfaces.

I was also surprised that I could not find much on the web of others creating BDA based applications. The only real thing I could find was a group on sourceforge.net.

Cheers
Darren

I think the best approach would be to write a DLL that is a subset of managed directshow. This way you keep the c++ side to a minimum and allow a fair degree of control in C#.

The alternative is to write all the directshow stuff in c++ and provide an interface to C#. With the number of options that you'd need in a good tv viewing app you'd need quite a detailed interface on the dll. Plus this is the basically the model that TwinHan has used for their SDK and we wouldn't want to be accused of programming something anywhere near as good as a twinhan program. <!--emo&;)--><img src='http://forums.dvbowners.com/html/emoticons/wink.gif' border='0' valign='absmiddle' alt='wink.gif'><!--endemo-->

For the moment i'm happy to write in c++.

darro,

The reason you won't find many applications is because the drivers have to be available first. But without aplications no one wants to write drivers. Chicken and egg I guess.

As for managed DirectShow, from what little I've seen of MCE, I suspect there will be some kind of support in the System.Windows.Media namespace. As for whether we'll see this any time soon is unknown.

It may not debut until Longhorn, here's early API docs:
http://longhorn.msdn.microsoft.com/lhsdk/r...deocontrol.aspx

Of course my understanding of some of this may be wrong. But it may be best to stick with C++ for now.

I'm interested in being involved. My C# development has been limited to ASP.NET rather than Windows Apps, but I'm still keen.

Might be worth checking out http://www.codeproject.com/cs/media/direct...mediaplayer.asp. It has a sample app for writing a DirectShow Media Player in C# using an interop for the QuartzTypeLib.dll (ie DirectShow COM dll).

I hope you all have the latest DirectX SDK installed by now. There is a sample C++ application in the SamplesC++DirectShowBDABDASample directory.

It's written for ATSC but with very little work you can change it to DVB. If you are looking for code to familiarise yourself with BDA it's worth a go.

Because this work is limited to Windows XP, you really should be taking advantage of the Video Control (MSVidCtl) component. It should make programming easier. You can even add DVD playing to your application if you want to make a generalised media play.

I think this code sample is a little more complex but at least there are examples in C++, HTML and VB
SamplesC++DirectShowVideoControl


Spectrum

I'm quietly confident that my drivers won't crash your pc (no guarantees though) so I'm bumping them up to beta quality and making them available for general release.

Get them here http://home.swiftdsl.com.au/~spectrum/index.html

Spectrum

Great stuff. Worked very well for me (once I had registered all of the drivers). I'm going to have a go at Windows Media Centre (when time permits) and see how the cards go in there.

Does the driver work for DVB-S cards? I had a quick look but there is no tuning space defined and the one you supplied is (obviously) for DVB-T.

A few interesting side notes.

1. When testing the driver and using the Elecard decoder, I could get video on my second monitor which is on a PCI video card (Matrox G200). When using the InterVideo decoder, I couldn't get any video on the second monitor. I thought this was a hardware issue, but perhaps not.

2. When using the Elecard decoder, the image stretches to fill the window, but with the InterVideo decoder it is at source aspect ration (16:9). Not sure what this means, just something I noticed...

Hally,

The driver is only for DVB-t. I may work on a DVB-s version some time in the future.

Your side notes are specific to the MPEG decoders used - not driver dependent.

MCE won't scan Australian frequencies. I had to modify a Windows DLL to get it to scan - there may be a way to override the frequencies in the registry but I haven't found it yet.

Spectrum

Just a question on this... In graphedit it appears that there are DVB-T, DVB-S and DVB-C Network Providers. Do the capture/tuner filters need to be developed seperately, or should it be just a matter of plugging the different provider in front of them?

Also, what applications (or types of applications) might work with these drivers? The newest beta of VideoLAN Client for Windows supports a "DirectShow input", however it still only seems to detect my ATI Rage Theatre Video Capture device. I was hoping to pick up the BDA drivers, but perhaps I'm dreaming...

Unfortunately I'm an application developer and normally web based, so I'm pretty good at user interface, but nowhere near a driver developer, otherwise I'd offer some help.

My Tuner/Capture filter combo only supports Twinhan DVB-t. The addition of other types in a single driver set is possible but it's really a design issue. A hardware developer may implement DVB-t, DVB-s and DVB-c cards that share common elements (as the Twinhan hardware does). This would make it relatively easy to write a single set of BDA drivers for all three, but as I said, it's a design issue - you could just as well write 3 separate driver sets.

As I understand it, the only off-the-shelf software that's ready to go is Microsoft's Windows XP MCE. The application programming interface is (relatively) easy to program to so once more manufacturer's hardware/drivers are made BDA compliant, I'm sure we'll see apps starting to be written.

Spectrum

Check out the following article on Showshifter's DVB-T beta.

http://www.homemedianetworks.com/article.a...sp?ArticleID=43

They specifically mention support for BDA drivers to allow compatability with more cards. So a decent front end with Plugin support etc may not be too far off.

Unfortunately, I have had no luck participating in their Beta. They don't seem to want to know about Aus or Twinhan cards.

Darryl

I tried to join the beta list too, and I thought the fact that I'm a licensed user of version 2.0 might help, but they didn't respond. I've seen some comments on problems with channels in Australia on their forum, and not much mention at all for the Vision Plus cards.

I've updated the drivers to version 1.0.1.2.
A few small bug fixes as well as support in the .inf files for cards OEM'd by Chaintech. If anyone gets a hold of other OEM'd Twinhan DVB-t cards please contact me so I can add them also.

http://home.swiftdsl.com.au/~spectrum/drivers.zip

The new version is working for me now - the previous wasn't.

This is awesome stuff - twinhan (renura - hint hint :wink: ) should support you, as BDA drivers would give them a huge market.

BJ

Dare I suggest an XML doc. All of the above can read and write it - and you and I can too - without a copy of Access required.

BJ

P.S. Trying to AC3 working now...

Has anyone tried writing some DirectShow code to use the BDA drivers? I'm getting strange results that I don't get with GraphEdit.

ngoodchild, can you elaborate please?

BJReplay, in the end, all we want is a standard way of getting a tune request.

So in pseudo C++
Create an interface that all guide/store developers code to, and create various implementations.

interface IGuideStore {

ITuneRequest* getTuneRequestForProgram(ULONG ProgramNumber);

}


XMLGuideStore::IGuideStore {

// Constructor with no arguments
XMLGuideStore();

ITuneRequest* getTuneRequestForProgram(ULONG ProgramNumber);

}


And in an application:

IGuideStore gs = new XMLGuideStore();
// IGuideStore gs = new AccessGuideStore();
// IGuideStore gs = new SQLSvrGuideStore();
// IGuideStore gs = new WebBasedGuideStore();
// and so on.

...


// User has pressed 7 on their remote control
ITuneRequest* ts = gs.getTuneRequestForProgram(7);

CComVariant varTuneRequest = ts;

msvidctl.View(&varTuneRequest);


Maybe a standard programming interface to a guide store is what I'm thinking of.

Spectrum

The ShowShifter 3.0 DVB Beta is now available for anyone to download at https://www.showshifter.com/files/DVBBeta/. It doesn't state support for the VisionPlus cards, and I haven't tried it yet (still downloading). Just thought you might be interested...

Is it supposed to support BDA? It appears to include card-specific code. Let us know if you find out more.

Spectrum

I have just downloaded and am having a look now. I certainly hasn’t picked up the card (or driver) straight way. I cannot see any reference to BDA, although it does seem to use WDM as it has picked up an old USB Pinnicle box I have.

Still looking though.

Cheers
Darro

No luck with ShowShifter here... Only seems to support WDM drivers.

Hi All,

I re-confirmed that the Spectrum's drivers worked with Graphedit. Showshifter still would not see the card. I noticed that Hally has put a post on the showshifter forum. So I guess we may need to wait and see what they say (if ever).

May keep playing with it for a while.

Cheers
Darro

Does anyone know about signal strength on the Twinhan cards? From what I've seen so far, all you get from the hardware is a number between 0 and 100, but I don't know what kind of measurement this is. For the BDA driver I need to follow this spec for my function returning signal strength:

Gobbledigook to me. Are there any engineers out there that could take a guess on an algorithm to translate the Twinhan 0-100 value to the BDA +/- mDb value?

Thanks in advance,

Spectrum

Version 1.0.1.4 now available, recommended upgrade.
http://home.swiftdsl.com.au/~spectrum/drivers.zip

As I get more low-level experience with the hardware, I'm seeing that it's quite susceptible to PCI bus latency issues. The onboard buffer is very small and it needs to pump data out (via DMA) constantly. If the device can't get access to the PCI bus within time, it will drop data.

Now you have to realise every system out there is different. Different people have different things plugged in to their PCI slots. On top of that, different motherboard chipsets may perform differently. Of course for the most part this is not a problem. It's really only if you have hardware that hogs the bus for too long that you'll see a problem. Unfortunately the Twinhan hardware can't wait around forever for the bus to become available to it so it has to drop data and just keep going.

You don't see any of these problems in set-top-boxes because the manufacturer has total control over the hardware components. Bus technologies are usually different anyway but you can see why we have difficulty at times with all of our differing setups.

So keep in mind the things on your PCI bus when you build your system.

Next up - glitches. For the most part this is not down to the drivers, and even though I mentioned PCI latencies above, they are seldom the real problem either. So what is you might ask? From all the analysis I've done over the last few months, I think we can put most of the blame on imperfect reception of the transmitted signal.

We tend to think of glitches as blips in the picture, sometimes stuttering images or broken sound. When our reception is woeful we accept these things and look for ways to improve the signal strength/quality. There is a tendency, however, to forget that we'll always be subject to glitches even when we think the signal is otherwise perfect. Remember that this is digital data, zeros and ones, and when the picture looks good and the sound sounds perfect you can mistakenly think that all those zeros and ones must be correct.

The transmitted signal actually contains a lot of overhead. It's there for the sole purpose of correcting errors that get into the signal on the way to your receiving equipment. You've probably heard elsewhere that it's not the signal strength that really matters - it's the signal quality. But even this can be misleading when you're looking at the little signal bars on your set-top-box or pc software. Even if the signal quality looks to be near 100% this is only an indication of the average over some sample period.

The networks broadcast something in the order of 20megabits of data each second. So while everything looks fine, all it takes to ruin your lovely display is 1 errant bit in that 20 million in just the wrong place. If it turns up somewhere in the middle of the video or audio data, you may not even notice it. If it's in a control datastream, or audio or video header, however, all havoc can ensue.

One in a million are pretty good odds, and that's every single second.

The hardware will try to recover from transmission errors, what it can't recover, the software will try to fix, and what the software can't appears on your screen or emanates from your speakers as glitches.

So you see, the odds are actually stacked against us. Welcome to the digital age.

All I can suggest is that you try to get the best quality signal you can.
Play with different codecs as some are better able to recover from errors.
Carefully plan the components in your PC so they don't hog the bus.
And enjoy the ride, I for one, am having great fun!

Spectrum

Spectrum,

Thank you for summing it up so well <!--emo&:)--><img src='http://forums.dvbowners.com/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->

Cheers

Renura

Spectrum, did you get any takers on developing an application using the BDA drivers? I'm keen to help if the development is in C#, but I haven't seen any takers yet. I saw mention of trying to port DigitalWatch, is that still an option?

Mmmm...Interesting. One of the things I'm finding (as discussed in another topic) is that the coding standard for the drivers is very poor. I haven't yet tackled the data transfer parts of the code, but if the rest of the driver is any guide, then it's clear that the driver is not working as efficiently as it could.

Another example I discovered yesterday is that when the driver sends a command to the I2C, it waits for the hardware to complete by polling a flag that is set by the interrupt handler. I don't think I'm missing anything here, but the whole point of an interrupt handler is so that you can post an event to wake up the waiting thread. It's just a waste of resources to sit around polling a flag. It gets worse cause the driver uses the high resolution performance counter in the polling loop to test for a timeout. This is pretty much a resource hog. It's a bad design made worse by a poor implementation. I'm currently changing the design to work on a simple event wait and post.

So, if the rest of the driver is performing so badly with such a time-critical device, then I can't help but think its gotta be contributing to the data loss.

P.S. Speaking of DMA, the driver requests an allocation of over 5MB contiguous buffer space to handle the DMA transfers. During my testing I noticed that after stopping the device and restarting it, I was unable to get a successfull allocation of that much DMA buffer space. I've got a pretty beefy system, so I can only imagine that such allocation failures are going to happen more frequently on smaller systems. These sort of failures will never be diagnosed correctly, and may simply appear as random errors when you try to start an application such as VisionDTV. Again, it's possible that a more efficient driver implementation may allow this buffer requirement to be reduced, thereby helping overall system performance.

Cheers,
Brian

[quote="eastsydneyboy"][quote]
P.S. Speaking of DMA, the driver requests an allocation of over 5MB contiguous buffer space to handle the DMA transfers. During my testing I noticed that after stopping the device and restarting it, I was unable to get a successfull allocation of that much DMA buffer space. I've got a pretty beefy system, so I can only imagine that such allocation failures are going to happen more frequently on smaller systems. These sort of failures will never be diagnosed correctly, and may simply appear as random errors when you try to start an application such as VisionDTV. [/quote]

Maybe this is why people sometimes get the "LNB power on Error". ?????

more likely that annoying 'failed to play program' or 'timeout' at startup or channel change.

Any tips on getting MCE 2004 working with the DVB-T card? I get "Video Error. Files needed to display video are missing or corrupt. Please restart Media Center and/or restart the computer."

I have the BDA drivers installed and working in GraphEdit.

Any suggestions welcome.

Your MPEG Video codec needs to be able to connect to the VMR9 renderer. Cyberlink codecs do not. Try Intervideo or Sonic or others.

Once you have that working, you still need to scan the channels - these are hard coded for European channels at the moment, you'll need to edit a DLL with a hex editor with your local frequencies unfortunately. Oh, and set your computer's location to Germany to be able to select DVB-t in the first place. (UK and others may work too but Germany doesn't fill your Guide with default channels).

The DLL in question is psisdecd.dll, it's located in about 3 different places under WINDOWS and you'll need to replace them all. They're protected by the O/S so you'll have to boot into safe mode to overwrite them.

Edit a copy of psisdecd.dll. The frequencies are stored as little endian DWORDs. Search for the first channel - 473833000 which is 1C3E1E28 hex and stored in the file as 281E3E1C. Then overwrite those frequencies with your local ones. Reboot into safe mode and copy the new file over the existing one where ever it exists under WINDOWS (3 copies from memory).

Let's hope Microsoft release MCE2005 for Australia some time

Spectrum

I have just been playing around with the BDA drivers.

Below is a little HTA (IE Browser Application). (cut and paste this into a text file with an extention of .hta, if you dare)

It does not seem to tune at all, I think it may just be taking the last setting of the card (as set in graphedit).

I do get a good picture. Sound is no go though, jumps all over the place. I suspect this may be due an incorrect rendering of the audio component or the control is just garbage. I have only just started to have a look at it and given the card is not in my development PC it is a real pain.

The other issue is that documentation for this is pretty scarce.

But it is interesting what can be done in a few lines of script.

Cheers
Darren

<html>
<title>TV Test</title>

<HTA:APPLICATION ID="TVTest">


<head><body>

<OBJECT ID="MSVidCtl" CLASSID="CLSID:B0EDF163-910A-11D2-B632-00C04F79498E" WIDTH="100%" HEIGHT="100%"></OBJECT>

</body></head>

<script language=vbscript>

Dim objTuner
Dim objTSContainer
Dim objTuningSpace
Dim objTuneRequest
Dim objLocator

Set objTSContainer = CreateObject("BDATuner.SystemTuningSpaces")
Set objTuningSpace = objTSContainer("DVB-T")
Set objTuneRequest = objTuningSpace.CreateTuneRequest
Set objLocator = CreateObject("BDATuner.DVBTLocator")

objLocator.Bandwidth = 7
objLocator.CarrierFrequency = 191500 ' Hard Coded to Nine Sydney
objTuneRequest.Locator = objLocator

MSVidCtl.MaintainAspectRatio = "True"
MSVidCtl.View objTuneRequest
MSVidCtl.Run

</Script>
</html>

That works a treat! Looks like I've got some playing to do... Sound works for me too, though the aspect ratio doesn't. Picture is stretched vertically. There goes my work for the night ;-)

darro,

I did the same a while back. This one is based on the microsoft sample but modified to suit DVB only. It also assumes you have registered Spectrum's tuning space.

This one has correct aspect and you can also change channels.

Instructions for use:

run html file
Type in frequency (eg 177500) press enter
Type in SID ( for 7 SD Sydney 1312) press enter
Then press 'Power On' button

It will take a second to render the graph then play.

If you want to change SID you can do this on the fly, just change Channel (eg 1316, 7HD Sydney) and it will change. If you want to change frequency it is advisable to press 'Power Off' the re-enter frequency and SID.

Let me know how you go.....


http://carey2.customer.netspace.net.au/viewdvb.zip

Andrew

Is it possible to do a similar thing with the standard drivers rather than the BDA drivers, ie use them in an HTA with the MSVidCtl component?

This disscussion have realy saved my day. Been loocking for info on PsisDecd.dll for a month now.

I have allso been trying to get XP Mediacenter to work with a DVBs card.
Have the BDA drivers(technotrend) , and can get Graphedit running DVBs channels, but only on a PC (std. XPpro.)where Mediacenter is not installed.

If trying on a Mediacenter pc GraphEdit locks after 2 seconds when tuning into a channel.
Have to use on/off switch to shutdown pc.

Cant figure out what is wrong. Do You have any sugestions?
Iv been told that microsoft has made some misstake in PsisDecd.dll, an that this is the reason.


Please exscuse my english, im from the other side (Norway )

Hi, I'm new to Media Center stuff but not to programming, so maybe I can help on this. I've developed som MS WebTV so what people are trying to do here is very exciting for me

Anyway, I have a problem with MCE in Portugal. It does not scan the Portuguese channels.

I've read that Spectrum managed to MCE scan Australian with some hacking. My question how can I do it for Portugal too so that I can start testing applications. I just need some pointers towards how to do it.

Thanks in advance for any help

Has there been any progress on these BDA drivers since December?

I'm quite interested to see how these go, so the VisionPlus can be used in a wider range of software.

I dunno how complicated the code is but maybe you could release the source so others can add/modify stuff and keep the project going

- James

There has been very little interest in this project so I'm just maintaining it for my own personal use. As few people will have access to the DDK there's not much point in releasing the code (not that I wouldn't appreciate help from someone knowledgeable if they should be interested).

Spectrum

I will be interested, just not yet Little early in the technology lifecycle for me...

Is anyone even attempting an open source BDA architecture app yet (active development not dreamware) ?

The source filter gives you the transport stream which you can demux into all the streams it contains etc. The main problem for me is working out how to mux the elemental streams back into a PES stream to save to a file.