About WDM Video Capture

This article provides an overview of video capture using the Microsoft® Windows® Driver Model (WDM) and Microsoft® DirectShow®. It describes the close association between WDM video capture and DirectShow.

This article also briefly describes the close association between the Stream class and WDM Connection and Streaming Architecture (CSA) and video capture minidrivers (which are clients of the Stream class driver). However, you should have a basic understanding of these topics before reading this article. For background information, see http://www.microsoft.com/hwdev/desinit/.

This article contains the following sections.

A Brief History of Windows Video Capture

Microsoft released Video for Windows 1.x in November 1992 for Windows 3.1 and optimized it for capturing movies to disk. Since then, video capture rates have risen dramatically due to use of the PCI bus, bus mastering controllers, NT striped sets, Fast/Wide SCSI, and direct transfer of captured video from adapter memory to disk without data copies. Despite capture rates that now exceed 20 MB per second, and a large number of clients for Video for Windows, deficiencies in the Video for Windows architecture exposed by the emergence of video conferencing required development of a new video capture technology.

The Video for Windows architecture lacks features important to video conferencing, television viewing, capture of video fields, and additional data streams such as vertical blanking interval (VBI). Vendors have extended Video for Windows by implementing proprietary extensions, which are product specific, to circumvent these limitations. However, without standardized interfaces, applications that use these features must include hardware-dependent code. The tight coupling between Video for Windows capture drivers and display drivers means that changes made to capture drivers require changes to display drivers as well.

In addition, the Video for Windows interface, AVICap, doesn't work well with DirectShow because AVICap allocates buffers. If DirectShow is accessed through AVICap, the buffers must be copied at the transition point, which is very inefficient. With the integration of DVD, MPEG decoders, video decoders and tuners, video port extensions (VPE), and audio codecs on single adapters, a unified driver model that supports all of these devices and handles resource contention is needed.

WDM Overview

WDM video capture was designed to resolve the problems inherent in the Video for Windows architecture. The main advantages of WDM video capture are:

Because of the large installed base of Video for Windows applications, Video for Windows drivers will continue to be used for devices that are primarily used for capturing movies. Version 1.1e of Video for Windows currently ships in Windows 98 to provide operating system support for these devices. However, the WDM video capture architecture provides optimal support for capture devices used primarily for TV viewing and video conferencing.

DirectShow supplies backward compatibility for Video for Windows applications without the shortcomings of Video for Windows. WDM video capture aims to provide additional support for the following: USB conferencing cameras, 1394 DV devices, desktop cameras, TV viewing, multiple video streams support and VPE capture support. This support is provided through kernel-based streaming.

WDM-based streaming extends the nonkernel streaming of DirectShow by providing a kernel connection. Streaming services are processed by the WDM Stream Class Driver and other cross-process system software components. The WDM Stream Class Driver is also responsible for calling a minidriver, which is a hardware-specific dynamic-link library (DLL) provided by IHVs to support device-specific controls. The minidriver and the Microsoft-provided WDM Stream Class Driver work together to provide low-level services for the lowest latency streaming, and DirectShow provides the higher-level features specific for your application. Because the Stream class supports a uniform streaming model for standard and custom data types, and supports data transfer between kernel drivers without requiring a transition to user mode, it is a highly efficient mode to use.

Previously, DirectShow filters transmitted data to and from the kernel whenever necessary to achieve things like decompression or rendering. Unfortunately, each of these transitions of the data stream from user mode to kernel mode was time-consuming because of the transition itself, and because of parameter validation, security validation, and possibly data copying, that must occur.

Through kernel streaming, a stream makes fewer transitions between user and the kernel mode. It can be either partially or entirely produced and consumed in kernel mode. When streams are processed in kernel mode, the DirectShow filters merely expose control mechanisms to direct the streams. This greatly reduces the overhead associated with numerous transitions between modes.

Kernel streams can pass data to the filter graph at appropriate points, depending on the application. The following diagram illustrates the transition to user mode.

Kernel streams

During video capture, the Stream class passes uncompressed video data back to the video capture filter for writing or rendering. Also, because kernel streaming supports multiple streams, other types of data contained in the stream, such as timecode or closed captioning, could be passed up simultaneously.

WDM Video Capture Architecture

The following diagram shows the three basic components of the WDM capture architecture.

WDM capture architecture

Because the WDM capture architecture was designed to integrate smoothly with DirectShow, it is straightforward to build capture graphs in DirectShow by using WDM capture filters that send control messages from DirectShow into the streaming class. The Ksproxy.ax, Kstune.ax, and Ksxbar.ax filters, which shipped in the Windows 98 Device Driver Kit (DDK), enable WDM streaming data, such as data from Universal Serial Bus (USB) conferencing cameras, 1394 DV devices, TV viewing, and desktop cameras, to be easily controlled and sent by the Stream class to the DirectShow capture graph. The following diagram demonstrates how these components are integrated into the basic architecture.

Components of WDM capture architecture

In this diagram, the Ksproxy.ax, Kstune.ax, Ksxbar.ax, and other DirectShow filters communicate directly with the Stream class. The Microsoft WDM Stream class, through its participation in CSA, transports high-bandwidth, time-stamped, latency-sensitive data streams between kernel mode components or between kernel mode drivers and user-mode components. Through CSA, the Stream class works well with DirectShow in that it shares media types, has similar streaming states (Stop, Pause, and Run), and shares the same concept of pins and connections. This provides an easy transition of data from the Stream class to the filters in the filter graph.

The Ksproxy.ax, Kstune.ax, and Ksxbar.ax filters also have supporting minidrivers (or one minidriver that supports all three). Video capture minidrivers are clients of the Stream class and control hardware devices that produce streams of video images and related data. These minidrivers provide the following functionality:

Stream class video capture drivers can support multiple, simultaneous streams of compressed and uncompressed video, timecode, closed caption, raw and decoded VBI data, as well as custom data formats. For each data type that can be produced simultaneously with other data types, the driver should create a new stream. The Stream class exposes each stream as a separate WDM-CSA pin. Each stream can be connected to another WDM-CSA kernel filter, or it can make the transition to user mode and flow on an output pin of a DirectShow user-mode filter. Each stream (or pin) can support a variety of different formats. For example, a single pin can provide RGB16, RGB24, YVU9, and JPEG digital video. For more information on minidrivers, see the Windows 98 DDK.

Filter Graph Configuration

The association between DirectShow filters and CSA makes DirectShow filters a powerful and relatively safe method for manipulating data from a kernel mode Stream class driver. The flexibility of DirectShow makes numerous configurations of filters possible. The following diagram shows one possible configuration of user-mode DirectShow filters for simultaneous preview and capture of video to disk.

Configuration of user-mode DirectShow filters

In this diagram, an incoming TV signal can be tuned in with the Tuner filter and routed with the Crossbar filter. The filter graph passes data in various streams to the video or audio capture filters to be saved on disk. This includes audio streams, video streams, and any other ancillary data in various streams such as SMPTE timecode or closed captioning data.

WDM Capture Interfaces and Filters

The WDM capture interfaces exposed by the kernel streaming filters are IAMTVTuner, IAMCrossbar, IAMAnalogVideoDecoder, IAMVideoProcAmp, and IAMCameraControl.

Some of the Windows 98 video capture filters for WDM are Ksproxy.ax, Kstune.ax, Ksxbar.ax. See the Windows 98 DDK for more information on these filters.

Top of Page Top of Page
© 2000 Microsoft and/or its suppliers. All rights reserved. Terms of Use.