A bit of the Story/History maybe?
This driver was written because my video capture card
(a VHX) was not supported anymore by Aimslabs (In fact,
i suspect that this company has broken). At that time,
I was investigating about video compression, colorspace
conversion , etc, and I realized that more than 10 to
30% of the CPU time was lost converting from the RGB
color space to the YV12 planar color space that most
video compressors use. But my driver was working bad
at that mode (in all modes I have to say, later I will
explain why) , I decided to investigate on the chipset
capabilities, I did get the datasheet, and I found that
the chip was able, not only just to capture at full
PAL size (768x576) : It was able to capture at full
framerate, individual fields at full size. But that
wasn't working with the drivers of the Card. Also the
card can adjust Gamma (only RGB formats), adjust Sharpness
( Using the filters that it has incorporated inside
the chipset, and support nearly every analog video standard.
All this was implemented digitally (all process is digital
inside the chip, the video signal is digitalized as
the first step, better than most TV sets you can buy
right now in the market). I felt that to be unable to
use such a good chip was a shame, so I started to look
after information about how to write a device driver.
I have selected Windows as the OS, 'cause at this time,
there is a good (I won't say perfect 'cause some things
are missing, such as direct DMA to userspace) driver
for Linux (bttv). Also, there is a lot more very good
applications for video editing under Windows. While
I was looking for that info about how to write that
driver, I discovered that Microsoft was changing the
driver model from the VxD model that is supported under
Win95, to the new WDM driver model, that supports from
all the user applications the tuning of TV channels
through a normalized API, selecting video sources, audio
modes, etc. and that driver would work on all the new
Windows OS, as Win98SE, WinME, Win2000 and WinXP. Due
to that cause, I decided to write a WDM driver. This
was the start of the nightmare!!!! I downloaded the
Win98DDK: Inside it ... Incredibly, a (very buggy, very
alpha) driver for Bt848 based boards driver. I took
that driver as the starting point. Soon the driver was
rewritten from scratch, to clean it, implement all the
missing features I wanted it to have, support all the
things the chipset supports, and make it stable and
reliable. I think the driver has reached this condition.
Then I downloaded the Win2000DDK... The driver wasn't
anymore bundled with that DDK.... Guess! I will explain
some things I have found while I was writing this Driver:
- I have discovered that the original driver found
in the Win98DDK was based (maybe written) on the original
driver written by Brooktree. So , from now on, I will
acknowledge as the original authors of the original
code (NOT the driver you have now) to Brooktree (then
Rockwell, now Conexant).
- The WDM model is still (obviously) under development.
I have found plenty of bugs (non documented behaviour,
things that don't work as they should) in the interfases.
They say that this should work in this way (Microsoft)
, but it does not . Some of the limitations of the
driver are due this.
- They don't tell you, but when you update DirectX,
you are updating the WDM layer (at least, the Video
part) also.
- The WDM to VFW (Video for windows) wrapper assumes
some stupid things about capture and preview channels
(for example, keeps previewing (overlay mode) at full
frame size, and capturing at a quarter size instead
of setting both channels to the same size). This leads
to a preview degradation, not to mention that Bt8xx
does not support capture and preview (based on overlay)
at the same time at full frame size. So, I had to
implement a sort of priority channel capture, that
ensures that the capture channel has priority over
preview...
- I had to implement variable framerate at the driver
level. Microsoft documentation says that the WDM layer
should handle it automatically, but it does not. It
simply tells the app. that everything is fine, but
gets the maximum framerate from the driver... Guess
what will happen with that little 2 fps AVI you were
going to digitize...
- NetMeeting needs to have a VideoInfo with AnalogStandard
set to None this one is the one it uses .... Well
...
Read the source code if you want to learn more! This
is really boring stuff!
|