AVS Forum banner

81 - 100 of 141 Posts

·
Registered
Joined
·
1 Posts
This is exactly what is needed. I was hoping that native drivers would be developed by either Microsoft for their MC, Motorola or even by a cable company but it doesn't look like this is going to happen.


I hope you are still finding time and motivation to work on this interesting problem. If not perhaps you would consider sharing what you have to an open source project.


Thanks for your effort! This could bring change to everyone, not just the ones who like to geek out.
 

·
Registered
Joined
·
734 Posts
this is the single most important topic on avs forum.

i tried to capture using win7 32 bit and could not get it to recognize my stb had to go back to xp so i could capture again. i to would happily pay for a reliable win 7 32 bit driver, hope john or someone else can crack this egg
 

·
Registered
Joined
·
3 Posts
I'm following this thread as well and amazingly interested in the outcome. Is this the only known effort trying to resolve this, or do others know of other projects trying to tackle this too?
 

·
Registered
Joined
·
44 Posts
Discussion Starter #84
Hey All, I know an update is long overdue. Sorry about that.


It seems like whenever I promise some deadline I get hammered by other things, and lose all of my momentum.


I still have a strong interest in seeing this through, but I've just been SUPER busy. I work at Sony, and we're kind of crunching to finishing God of War 3. I've been working crazy hours like from 10am to 11pm + weekends.



Also on top of the crunch at work, I'm buying a condo and I'm just about to close escrow and move. So, assuming I can build up some more momentum on this, I probably won't be able to make much progress until around Christmas at the earliest.


That being said, here's where I stand with the project:


Unlike regular software development where you can debug the program in question with another process on the computer, you are working at a layer at or under the operating system level which means if you need to stop the program to analyze what's going on, the whole OS must stop. So you cannot do debugging on the same machine unless you basically take a snapshot and let the process keep running and then try to analyze the snapshot after it's done and gone. I've never got that to work and besides if you crash, your whole system will blue-screen of death so there's no chance of reading that snapshot. Instead what must be done is to have a second machine to do the development, and to use a special cable between the two machines. The choices for cable is null modem cable (which most modern machines don't even have ports for), debug usb cable (which is hard to find), or a firewire cable. Firewire! perfect right? well, the driver I'm writing is for a firewire device and we have to tell the OS to use the firewire controller as a debug host. Luckily there is a salvation, you can use a second firewire controller (I bought a pci express expansion card). And then you set one for the debug connection, and the other to connect to the device.


Another hurdle is that once the driver is made, in 64 bit vista/win7 it MUST be signed. For development purposes we can create a test certificate, boot windows in a special testing mode, and sign the driver with a self-made test certificate. However once released, other people would have to take the same steps, or it would have to be officially signed, which would cost around $500.


Further, now that I've dug way into the development, I've run into a bit of an information barrier, in understanding how the protocols work between the devices. Acquiring said information is not free, there are organizations that charge for the information such as 1394ta, iec, and ieee.


I have been able to successfully send a lot of commands to the device and managed some control over it, however using the high level interface provided by windows to support the mpegTS, the format we need to deal with, I ran into some setbacks where either the device doesn't communicate properly with their middle level driver, or I set up the inputs incorrectly. In either case debugging the problem is near impossible, as I have to step through disassembly and trying to analyze registers is cumbersome and difficult. So, I acquired a good portion of the documentation needed to understand the underlying formats and device communication at a much lower level that what I was previously attempting. My hope is that I will send more specific commands, instead of high level bundled instructions and hoping everything in the black box middle driver does what it's supposed to. This will hopefully allow me to break through my current obstacle and I'll have one of two outcomes. I'll coerce the middle level driver to work with the device as expecting using accurate inputs, or I'll replace the middle level driver completely and work entirely at the lower level.


Due to the costs of development, parts for debugging, documentation, and possibly the proper certifications if I were to properly distribute the driver, I think that if I remain the sole developer and charge a fee to purchase the driver, I would be able to make a properly certified and functioning driver.


On the other hand, the challenges in developing the driver are rather extreme, and if there were other people that could make a considerable contribution, I'd consider making it open source. This way, it may get done faster, and have more support for stability and features. However the copyrighted documentation could not be redistributed, and the driver would never have the proper signature and would require the end user to test sign the driver and run their operating system in testing mode.


There is also a possibility if I remain the sole developer and keep everything closed source that I may be able to properly support 5c encryption. I've heard people say the firewire controller must be recognized by 5c encrypted devices to work, but I've also heard it's just an authentication protocol, with a shared key. If the latter is true it may be possible to properly support it, as a closed source solution under contract with 5c.


So what do you guys want? Open source, or properly signed and *possibly* 5c compliant?


Thanks for your support either way.

I look forward to finding the time to make more progress on this.


`John
 

·
Registered
Joined
·
78 Posts
I don't know about anyone else but, personally, I'd prefer a commercial, properly signed driver, and would pay a reasonable price to purchase this even if it wasn't 5c compliant, compared to an unsigned, open source driver.


Jerry
 

·
Registered
Joined
·
136 Posts

Quote:
Originally Posted by GBarber /forum/post/17540264


I don't know about anyone else but, personally, I'd prefer a commercial, properly signed driver, and would pay a reasonable price to purchase this even if it wasn't 5c compliant, compared to an unsigned, open source driver.


Jerry

I'm of the complete opposite position. A closed source driver is useless.


How would you handle 5C support, anyway? Would it require the use of Media Center? If not, how would the encrypted content be playable? Would there be provisions for archival storage on BD-Rs?
 

·
Registered
Joined
·
44 Posts
Discussion Starter #87
Well, I'm not making promises, but I can be fairly certain no open source software would ever get the support from 5c. It's probably not possible because once the media is in digital form available on the PC there's little anyone can do to prevent it from being copied. digital rights management is a nightmare I wouldn't want to get into. Apple has somewhat succeeded. You can legally download videos from the apple store, but you can't legally redistribute them. If 5c would allow a PC to access their copy once material it would have to fall into a similar category. As for reading the encrypted data, I just meant if it could be done officially, it'd probably be a simply private key decryption.


The only other thing I can think of is that it would be able to record the show in encrypted form, and then you'd need custom software to real-time decrypt and display, but that would get cracked so fast.


On second thought, I doubt decrypting 5c on PC will happen because there is too little control of the media once it's decrypted on the PC.
 

·
Registered
Joined
·
35 Posts
I have a Scientific Atlanta 8300HD and 64-bit Windows 7.


I'd suggest a no-frills open-source version, and a closed-source version with 5c support if it can be done.
 

·
Registered
Joined
·
791 Posts
Well if you go Open Source, you'll never be able to get the driver signed properly correct? No one wants to go through all the hurdles to get the Windows Kernel to bypass driver signing. What a hassle. I think for most people, they want to run a setup.exe, reboot once, connect the cable and have everything work.


Supposidly channel change commands can be sent over the firewire bus to the set top boxes. I wonder if there is some provision to fully integrate a commercial driver with Windows 7 Media Center? Win7MC would have to 'see' the cable box as an available tuner, and send proper channel request commands to it, while displaying the audio and video (or directing it to be recorded to dvr-ms files.)


Could you imagine the awesomeness of such a project if it were to work? I mean, if the user already has a firewire equipped Windows 7 PC, and they already rent the cable box... there's nothing else for them to purchase, except maybe the driver software.


Ceton is releasing a quad tuner PCI-E card in early 2010 for media center. But then you get into the whole cable card dibacle. The Cable company has to come out and install it. You rent the cards, they blame you if they can't get it working... I know it's a dream, but if I could use my already functional cable box, but pretty it up with Windows 7 Media Center user interface, we would be living large.


Go for the closed source development. This way you can get proper driver signing. Maybe you can get some help from various users out on the internet, as in input, and stuff, but don't open it up to the whole world if the people responsible for 5C or Microsoft would have a problem with it. For it to be truly successful, 5C is a must. When analyzing the data on the firewire bus, when the 5C flag is on, data is still sent. It can still be captured and played back... it's just encrypted. The data is physically there. Nothing prevents the Cable box from transmitting data when the 5C byte is enabled. I know there has to be some way to decode this data. Just can it be done in real time for a full HD stream?
 

·
Registered
Joined
·
35 Posts
My thought is that both the open and closed source versions would be signed, but only the closed have 5c. Does Microsoft require that a driver be closed source to be signed?


I understand signing costs money, but I think 5c would be enough of an incentive that it could offset making the signage a freebie.


At the very least, an open source driver could be further developed and expanded upon by others.
 

·
Registered
Joined
·
136 Posts
The biggest problem with a closed source driver is, what happens if John can't maintain it anymore? It stagnates, eventually becomes broken and useless, and the community is in the same situation we're in now. Open source means more eyes on the problems, and more eyes (if not mouths) is a good thing. If it were confirmed to be open source under a robust license, I'd most likely donate cash to it. Unfortunately I'm a web and user interface developer, not a device one, so I couldn't donate much skill.


Knowing the consortium that manages DTCP/5C, and given the existence of CableCard tuners, if it somehow was granted permission to capture 5C encrypted content, it'd just be yet another Microsoft Media Center lock-in mechanism, which is entirely not compelling. Closed source, commercial, with DTCP license fees and Microsoft lock-in? Why bother? I'd just get a CableCard tuner and not have to deal with flaky STBs.
 

·
Registered
Joined
·
78 Posts

Quote:
Originally Posted by bwer /forum/post/17553698


The biggest problem with a closed source driver is, what happens if John can't maintain it anymore?

And the biggest problem with an open source driver may be in getting the driver signed. I think the ultimate answer depends on the intended audience since that will determine the importance of having a signed driver that non-technical/non-programming individuals can easily install and use.
 

·
Registered
Joined
·
3,525 Posts
As a former 5C developer, I can tell you that it's very difficult to accomplish for many reasons.


1) First off, it's $10,000 just to get an evaluation license. $14,000 if you want to actually build a product.


2) Each device (each PC) needs it own unique set of keys.


3) You can't have unencrypted content available anywhere in the box. You have to do what Ceton does with their cable card product and re-encrypt to the Microsoft DRM format.


4) No PC based IEEE1394 card has a controller that supports 5C decryption. The typical STB or D-VHS deck IEEE1394 controller has the decryption cipher built into the silicon and decrypts the packets on the fly. If you don't do it on the fly, then you have to keep track of when the scrambling key changed (it changes every 30 to 40 seconds) and which key is current (even or odd). To make matters even worse, all PC IEEE1394 controllers are OHCI based, but no 5C capable STB/D-VHS IEEE1394 controller is OHCI based.


I could go on and on.


Ron
 

·
Registered
Joined
·
2 Posts
All,


I work for a graphics organization (not sure if I'm allowed to say with one). I'm on the hardware side and can't immediately support this effort myself. But what I will do is ask around to find out who is our video driver expert and see if I can ask non-proprietary questions on AVCstream and/or lower level drivers. Note, I could try to dust off my C/C++/OOP but it's not likely I would be useful to this effort in the near term.


Also - I would pay ~$50 for a 64bit windows 7 driver. I'm moving my dual firewire channel changing/recording machine from Vista-32bit to Win7-32bit and it's annoying that we're stuck with very old firewire drivers. I would pay another $50-100 for the ability to record 5C copy once data. In general, I like the idea of the non-5C being open source (with properly signed driver) and the 5C potentially being closed source. Like most of you probably, it's very upsetting to me that recording HD content that I'm paying for is made to be so difficult.
 

·
Registered
Joined
·
2 Posts
Johnb008, All,


I found the right contacts to ask about AVStream (and other) driver details. But could someone (ideally Johnb008) clarify the driver/software stack of interest. Johnb008 talks about high, middle, low level drivers used with mpegTS. I'm a hardware designer with solid programming skills. But driver stacks, etc, are not my area. Ideally, I'd be looking for a simple explanation with a diagram showing the software stack of interest. And, details on what information is currently missing so I know what to ask for.


A quick google search yielded this MSDN page on AVstream.

msdn.microsoft.com/en-us/library/ms802464.aspx


But, I don't want to dig into this if this isn't the info that is really being sought.
 

·
Registered
Joined
·
44 Posts
Discussion Starter #97
Ok, so let me try to clear a few things up.


To get the driver properly signed, it has to go through a pretty long process to get approved and the driver file hashes are stored with the certificate. So if changes are made to the driver it has to go through the signing process again.


So, if I did allow the non-5c version to be open source, it's not like people can just grab the latest changes and be up-to-date, it'd have to get signed again, and who'd pay for it?


If it's open source, it comes with all of the open source problems, and lack of commercial support.


As for supporting 5c, I've been trying to research it through contacts at Sony. It's no surprise to me that there's a pretty steep development cost. I work on games and it's really expensive to lease console development kits, as well as third party software licenses.


As dr1394 pointed out, it's $10,000 just to evaluate, and $14,000 for a small scale project, and $18,000 for large scale. Plus there's a cost per unit, depending on how many, the price varies.


It's fine to use the ohci compliant device, but the driver has to do all of the decrypting and converting without exposing the unencrypted stream. Further in order to get accepted for a 5c license I'd have to jump through lots of hoops to convince the DTLA that I'm taking all of the necessary precautions to hide the keys used to decrypt the streams in the first place.


There's a lot of research to be done as well for DRM support, and to make sure this whole scheme remains compatible with windows media center.


I don't think support for 5c is impossible, but I think it would need to be structured around a business model, with some form of investment funding, or loan to cover the costs of licenses, and development. This also requires a high enough demand, to make development even worth it. So there would also need to be a bit of initial research to see if it's even a big enough market.


If this were the case and the business was funded, some of the development could be contracted out to other developers besides just me, and would not just rely entirely on me.


Fortunately, I can develop the non-5c version without much investment. Just the cost of a second ohci controller for debugging, and protocol specification documents.


So far, here's what I'm planning:


I may share the source, but not under an open source license. I plan to keep the rights to the code. I don't mind sharing the code for people to help make contributions, but I'm going to keep the rights and front the costs for driver signing. If anyone is willing to go through the needed steps to do the development and wants to make a contribution, they may do so, but must be willing to give up the rights for the code in that contribution. I'll sell signed versions of the driver, and hopefully I'll make back the money for the costs to get it signed. If I don't make that money back, it's my loss. If enough people want to pay for the signed version and I make more money I'll put it aside to invest in development for 5c.


So, your choices will be:

* Get the source and make it work yourself

* Pay for the signed version and help support the development of 5c support


I'm still deciding. I might also decide to sell the source w/o signed driver for something like half the price of the signed driver, so there's some incentive to support the 5c development.
 

·
Registered
Joined
·
44 Posts
Discussion Starter #98

Quote:
Originally Posted by easperhe /forum/post/17591213


Johnb008, All,


I found the right contacts to ask about AVStream (and other) driver details. But could someone (ideally Johnb008) clarify the driver/software stack of interest. Johnb008 talks about high, middle, low level drivers used with mpegTS. I'm a hardware designer with solid programming skills. But driver stacks, etc, are not my area. Ideally, I'd be looking for a simple explanation with a diagram showing the software stack of interest. And, details on what information is currently missing so I know what to ask for.


A quick google search yielded this MSDN page on AVstream.

msdn.microsoft.com/en-us/library/ms802464.aspx


But, I don't want to dig into this if this isn't the info that is really being sought.

easperhe you're on the right track.


AVStream is the output side of the driver that communicates the stream to the end user and lets them record that to file, or view it directly. Eventually I'll implement a higher interface even to support the interface required for a tuner device.


Anyway, the input side of the driver comes from here:
http://msdn.microsoft.com/en-us/library/ms802416.aspx


This is the "high-level" driver I was talking about. Notice in this stack how AVCStrm sits above, the AV/C protocol, and that sits above the 61883 protocol, which sits above the OHCI controller. Basically, I tried to use that top level AVCStrm, but the interfaces were not well documented, see for yourself. And I couldn't tell what values to use to properly configure the stream.


I've since given up on the high level interface, and moved down to the 61883 level to establish a baseline and understand the lower level protocols. Once I understand this, I might try to use that knowledge to finesse the high level "AVCStrm" to work. If not, I can just write my own stuff at the "AV/C" level (which requires that you do a lot of stuff at the 61883 level anyway).


I actually suspect that the AVCStrm level requires that you do a lot of work on your own at the 61883 level anyway in order to work properly. We'll see.
 

·
Registered
Joined
·
293 Posts
are you able to make an updated driver for the DCX3400 box? its having major IEEE issues. id love to help if possible on that... apologies if this has been discussed and an answer to this has been answered...
 
81 - 100 of 141 Posts
Top