IPB

Welcome Guest ( Log In | Register )

8 Pages V   1 2 3 > »   
Reply to this topicStart new topic
> Programming to the Microsoft TV Technologies interface
Guest_Spectrum_*
post Nov 23 2003, 12:27 PM
Post #1





Guests






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
Go to the top of the page
 
+Quote Post
renura
post Nov 23 2003, 01:08 PM
Post #2


Enthusiast


Group: Members
Posts: 6,668
Joined: 10-July 03
From: Canberra
Member No.: 38
Card: None


Spectrum,

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

Cheers

Renura
Go to the top of the page
 
+Quote Post
Guest_AndrewPC_*
post Nov 23 2003, 02:36 PM
Post #3





Guests






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
Go to the top of the page
 
+Quote Post
nate
post Nov 24 2003, 09:15 AM
Post #4


DigitalWatch Developer
Group Icon

Group: Admin
Posts: 2,267
Joined: 30-September 03
From: Melbourne
Member No.: 169
Card: DNTV Quad


QUOTE
I'm looking for anyone who wants to write a program using the Microsoft TV Technologies interface
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.


--------------------
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Nov 24 2003, 09:48 AM
Post #5





Guests






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
Go to the top of the page
 
+Quote Post
nate
post Nov 24 2003, 10:14 AM
Post #6


DigitalWatch Developer
Group Icon

Group: Admin
Posts: 2,267
Joined: 30-September 03
From: Melbourne
Member No.: 169
Card: DNTV Quad


QUOTE
Hopefully it's just a matter of telling the MPEG2 Demultiplexer which PID to map to the audio output pin. ... The problem we may have is whether Australian AC3 streams are a recognised component type - I suspect not.
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.


--------------------
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Nov 24 2003, 10:15 AM
Post #7





Guests






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:
Go to the top of the page
 
+Quote Post
darro
post Nov 24 2003, 02:02 PM
Post #8


Forum Regular


Group: FAQ Maintainer
Posts: 458
Joined: 30-September 03
From: Sydney
Member No.: 168
Card: VisionPlus DVB-t


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
Go to the top of the page
 
+Quote Post
nate
post Nov 24 2003, 02:13 PM
Post #9


DigitalWatch Developer
Group Icon

Group: Admin
Posts: 2,267
Joined: 30-September 03
From: Melbourne
Member No.: 169
Card: DNTV Quad


QUOTE
"There are no current plans to implement a "Managed DirectShow" platform"
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.


--------------------
Go to the top of the page
 
+Quote Post
darro
post Nov 24 2003, 02:22 PM
Post #10


Forum Regular


Group: FAQ Maintainer
Posts: 458
Joined: 30-September 03
From: Sydney
Member No.: 168
Card: VisionPlus DVB-t


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
Go to the top of the page
 
+Quote Post
nate
post Nov 24 2003, 02:37 PM
Post #11


DigitalWatch Developer
Group Icon

Group: Admin
Posts: 2,267
Joined: 30-September 03
From: Melbourne
Member No.: 169
Card: DNTV Quad


QUOTE
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 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++.


--------------------
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Nov 24 2003, 02:48 PM
Post #12





Guests






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.
Go to the top of the page
 
+Quote Post
Hally
post Nov 24 2003, 05:59 PM
Post #13


Forum Regular


Group: Members
Posts: 234
Joined: 4-October 03
From: Melbourne
Member No.: 176
Card: None


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).
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Nov 25 2003, 09:19 AM
Post #14





Guests






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
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Nov 30 2003, 02:23 PM
Post #15





Guests






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
Go to the top of the page
 
+Quote Post
Hally
post Nov 30 2003, 05:21 PM
Post #16


Forum Regular


Group: Members
Posts: 234
Joined: 4-October 03
From: Melbourne
Member No.: 176
Card: None


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...
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Nov 30 2003, 06:15 PM
Post #17





Guests






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
Go to the top of the page
 
+Quote Post
Hally
post Dec 1 2003, 05:44 PM
Post #18


Forum Regular


Group: Members
Posts: 234
Joined: 4-October 03
From: Melbourne
Member No.: 176
Card: None


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.
Go to the top of the page
 
+Quote Post
Guest_Spectrum_*
post Dec 1 2003, 08:20 PM
Post #19





Guests






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
Go to the top of the page
 
+Quote Post
Guest_dormston_*
post Dec 2 2003, 08:20 AM
Post #20





Guests






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
Go to the top of the page
 
+Quote Post

8 Pages V   1 2 3 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2018 - 05:04 PM