Linux and DVDs

LinuxBroadway MPEG1 Project H.Q.

Dave Huseby

February 2, 1999

I finally put up the stripped driver on the download page so go ahead and grab yourself a copy. The reason it's taken so long is because of many reasons. First of all, I had written almost all of the functions necessary (from what I could tell from the specification) to get the Broadway card up and running but it wasn't working. So I tracked down the original author of the vt_acc.c (the hardware initialization stuff in the windows driver) code. I asked him some questions and realized I was going about things all wrong (it happens.) Anyway, he told me what needs to be done and what doesn't, the latter being more important in my case. So I stripped the source down to what I thought was one release past the 010599 release but I couldn't get it to compile. So I dove into the archive and pulled out the last version I released to the LinuxBroadway group and posted it. Right away there are some things that need to be done. I was writing the code to be cross-kernel compatible (2.0.x-2.2.x) by using Mr. Rubinni's sysdep-2.1.h header that does a nice job of putting band-aids over the 2.0.x code so that a 2.2.x kernel can use it. Now that I'm running 2.2.1 I'm going to be concentrating on that kernel version so that we can get this thing done. You'll notice that this code is rather skinny, but I told you it was just a barebones driver. It doesn't do anything 'broadway' related yet. I haven't had time to start porting yet. My custom broadway app for work is approaching the deadline so I'm spending most of my time coding that. In the little bit of extra time I have, I've been working on this web site so that it doesn't look like I've dropped the project. It is still very much alive. Here is a snip from the email I received from the original author of the vtaccess code.

"Unfortunately the Hardware register doc is incomplete in that it does not cover the VRP (C-Cube Chip) You should try to get a copy of the C-Cube 4111 doc from C-Cube or DT.

With the exception of VT_OpenDevice there is very little Windows code in vt_access. If you have not ported the VT-Access code for the module you intend to use. (probably I frame capture) there is no way it can work.

Minimum port best guess:

vt_acc.c
vt_user.cpp
mcode.cpp
capture.cpp
device.cpp"

As you can see, my main problem was the lack of completeness in the spec. I plan to start in on porting the vt_acc.c code this weekend. If you want to help, pick some code from the list above and port it. Submit the code to me through email and I'll merge the stuff and make it compile and post the new driver on the download page. The source files listed above can be found in the driver source which is also on the download page. Have at it.

February 5, 1999

I started in on the vt_acc.c port last night and on into this morning. I added a few files to the project. I added the C-Cube Microsystems header files, and some general board description headers. I'll need to go through each one and convert the types into something that will compile and integrate nicely into our driver. The files I added are: vt_regs.h, vt_vrp.h, vt_acc.h, 4100_ld.h, 4100_api.h, and 4000_reg.h. They all deal with the hardware issues like keeping track of the device registers and talking to the VRP. I'll post the updated tarball this evening. NOTE: these headers aren't included into the code because they haven't been ported yet. I just spent a few hours looking at the functions in the vt_acc.c file to get an idea of how this whole thing fits together. The headers from C-Cube define constants and prototype all of the functions necessary for running the VRP. vt_acc.c contains most of the code for the functions in those headers. That is what I'm working on for the next week or so. If anybody wants to start in on any of the other files listed below in my previous post, be my guest. Just email the changes to me and I'll integrate them in. From what I can tell, we'll be able to drive the VRP pretty good once I get a Linux version of the vt_acc.c compiling. Later.

February 6, 1999

I finaly feel like I've made some real progress. I decided not to post the new tarball yet. I was working on the vt_acc.c code and I started folloing the calls all the way down to the hardware level. I realized that I needed to start from the bottom up and then once I got back up to the vt_acc.c level I would integrate it into the existing code. I added a ton of new files that I ported over to C. I'm currently working on a Linux version of the mcode.c file. The mcode file contains all of the 'microcode' for talking directly to the VRP through the PCI bus. I'm about 90% done with that. As soon as that is done, I can port the higher level functions like the ones in vt_acc.c and vt_user.cpp. I also came to the realization that the broadway struct that I was using as the highest level object for each broadway card in a system is exactly what the CDevice class is in the vt_user.cpp code. So, I finish the microcode, convert the types in the structs and some of the high level calls need to be reworked, but all in all I would say that I am getting really close to being able to get some kind of video from this damn thing. It still may be a week or two but I've really got a direction with this now. Many thanks to Phil, the author of the original vtaccess code, he's help me out a ton. I promise you that as soon as the microcode is ported I WILL POST A NEW RELEASE. I doubt that it will compile because the foundation will be there as well as the roof, but there won't be any walls yet. In my optimistic opinion I would put overlay video at 2 weeks away and I-Frame capture another week after that. Because IBP-capture (MPEG) has some totally different code, I really can't tell you when Linux will become MPEG capable. If anybody wants to help, I'll have to meet them in an IRC channel to talk about it because I have lots of things to tell them. I really could use the help. Because the windows code is mostly in C++ I've been cuttin out code left and right trying to get it down to C structs and functions. I could really use somebody who knows both languages at least as well as I do. I need somebody to 'proof-read' the code. I just want another opinion on whether my code is the best way of going about this. Email me if you can help. I just spent 8 hours working on this thing and now I have a party to go to.

February 11, 1999

I finally ironed out the wrinkles in the micro code and I got the card to intialize!!! YEAH!!!! I am soooo close to getting overlay video!! Can you tell I'm happy? Let me clean up my code first and then I'll post the tarball. It may take me a day or two, I have some midterms over the next few days. I won't be around this weekend so it will have to wait until next week. Yesterday I did a full backup of my home directory tree and formatted my system. I know that's kinda drastic but I cleaned off my tweaked RH5.2/SuSE5.3 mixed system and installed the Pentium(tm) optimized Linux Stampede distro (www.stampede.org). This sucker flies (they say you get about a 5-30% increase in speed). I really noticed a difference. Besides, it's the only currently available distro that installs both kernel 2.2.1 and glibc2 in binary form. They've also integrated in the libc5 libraries well enough that I can run Applixware and other libc5 binaries just fine without any tweaking. The people behind Stampede have a good thing going. BEWARE though, the distro is not for the new Linux user. I had to do LILO, pppd, and X setups manually. But, after recompiling a custom kernel that didn't have every driver under the sun in it, my system got even faster :-) That's really good news for somebody like me who runs an aging P166. Well, I'm gonna leave you all drooling at the thought of realtime MPEG1 coming soon, I can already see the /. headline. BTW, my next project will probably be to figure out how to multicast the streams across the net once the driver is complete and in the stability testing mode. Later.

February 24, 1999

Status Report: 66% complete...

Once again, a new web page. This one is much easier to maintain and it doesn't crash Netscape anymore. The JavaScripting in the last page was cool but because of a bug in Netscape's interpreter, it wouldn't always show up right. Anyway, other big news...In somewhat of a controversial move, I have decided to adopt the V4L2 API instead of the standard V4L API that is currently shipping with the 2.2.x kernel. It is my opinion that the V4L2 API better addresses the issues related to the handling of specialized capture hardware like the Broadway MPEG1 capture card. In the V4L2 spec for instance, has the defines a standard for non-io opens on a device. This makes the long standing Unix tradition of having many little programs that do one task well easier to implement with video capture hardware. For instance, a general "control-panel" app can be built that will control all of the settings of all the video hardware in a single system. The control panel would run along side capture applications. The non-io open allows the control panel to open the device to get and set its settings but not capture video; that is what the capture app is for. Well, it makes the organization of the driver code a little easier, plus capture application writers really won't have to concern themselves with device setting control. This was just one of many issues that lead me to the decision. One more piece of big news...My boss John, asked me the other day if I wanted to write a driver for the MPEG2 capture card made by Video Tech. He proposed buying a few of them, getting the SDK, converting one of the NT paperweights into a Linux workstation and developing an open source driver for it. That means that I'd get paid to write open source ;-) Needless to say, I was all for it. I'm not sure if there is a God, but if there is, he digs open source software; I'm sure of it. That's it for me. I'm off to write the new V4L2 stuff and add the new time-stamping stuff to the microcode.