Last month I talked about how to write a device driver for radio-tuner cards. This month, I’ll cover video-capture devices, which share the same interfaces as radio devices.
Last month I talked about how to write a device driver for radio-tuner cards. This month, I’ll cover video-capture devices, which share the same interfaces as radio devices.
In order to explain the video-capture interface I will use the example of a camera that has no tuners or audio input. This keeps the example relatively clean. To get audio capabilities, you can combine this month’s driver with last month’s driver example.
Before I get into the details of video-capture devices, a little background on the technology is in order. Full-motion video, even at television resolution (which is relatively low) is resource-intensive. These devices continually pass megabytes of data every second from the capture card to the display. Because copying this amount of data through a user application is often unfeasible, several alternative approaches to television tuners have been developed.
The first is to transfer the television image onto the video output directly. This is also how some add-on 3D-rendering cards work, dropping the video into any chosen rectangle of the display. These cards, which include most MPEG-1 cards that use a feature connector, aren’t very friendly in a windowing environment. They don’t understand windows and clipping rectangles, which means that the video window is always on top of the display.
Chromakeying is a technique used by cards to get around this. It is an old television mixing trick in which you mark all the areas you wish to replace with a single clear color not used in…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including: