Testing Windows Video Capture

Drivers
Published June 17, 2004

Abstract
This paper provides information about testing video capture drivers for the Microsoft®
Windows® family of operating systems. It recommends tools and provides guidelines for
driver writers to debug video capture drivers in preparation for successful logo
submission.
This information applies for the following operating systems:
Microsoft Windows 2000
Microsoft Windows XP
Microsoft Windows Server™ 2003
Microsoft Windows Vista™
The current version of this paper is maintained on the Microsoft Windows Hardware and
Driver Central Web site.
 Testing Windows Video Capture Drivers — 2

Contents
Disclaimer............................................................................................................. ....3
Introduction........................................................................................................... ....4
Commonly Overlooked Test Scenarios................................................................. ....4
Plug and Play......................................................................................... ..............4
Power Management............................................................................. ................5
Display.......................................................................................... .......................6
Fast User Switching........................................................................................... ........6
Resolution Changes.......................................................................... ........................7
Buses and Devices................................................................... ...........................7
Multiprocessor Systems...................................................................... .................7
64-bit Systems............................................................................ .........................8
Essential Tools and Configuration for Video Capture Development and Testing......9
Computer Configuration for a Test........................................................................ 9
Driver Verifier.............................................................................. .........................9
DirectX SDK Tools.......................................................................................... ......9
AMCap................................................................................................ .................9
GraphEdit.............................................................................................. .............10
DDK Tools..................................................................................... .....................10
Sleeper............................................................................................... .....................10
DevCon................................................................................................................ ....10
KsStudio............................................................................................. .....................10
UVCView................................................................................................................ ..11
HCT Tools.................................................................................................... .......11
Blink................................................................................................................. ........12
MSTapeTst.................................................................................................... ...........13
ChkINF.......................................................................................... ..........................13
Call to Action.............................................................................. ............................13
Resources......................................................................................... .....................13
Microsoft Windows Hardware and Driver Central.................................. ..................13
Microsoft Windows Hardware Quality Labs....................................... ......................14
Microsoft Windows Driver Development Kits.......................................... .................14
Microsoft Windows DirectX........................................................................... ...........14
Appendix..................................................................................... ...........................15
Video Capture Functional Classifications and Definitions..................................15
"Designed for Windows" Logo Program Requirements Device Definitions........16
General Streaming Media Devices: Windows Compatibility....................................16
Encoders and Decoders: Windows Compatibility....................................................16
Broadcast Receivers: Windows Compatibility.................................................... ......16
Video Capture Devices: Windows Compatibility................................... ...................17

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 3

Disclaimer

The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it
should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the
accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS,
IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for
any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses,
logos, people, places, and events depicted herein are fictitious, and no association with any real company,
organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be
inferred.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, DirectShow, DirectX, Win32, Windows, Windows Server, and Windows Vista are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective
owners.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 4

Introduction
A video capture device is any device that receives external video or audio/video data and
provides a representation of that data in a digital format usable by the operating system.
This paper provides information about testing video capture drivers for the Microsoft®
Windows® family of operating systems. A small number of testing issues lead to a large
percentage of video capture driver problems. This paper presents several commonly
overlooked test scenarios that address these issues.
Driver writers can use a combination of older tools and recently released tools to improve
robustness of video capture drivers. This paper lists these tools and where they can be
found.
The appendix includes a list of video capture device classifications, definitions for each
category, and Windows Logo Program requirements for the different device types.

Commonly Overlooked Test Scenarios

This section describes common problem areas to look at when testing a video capture
driver.

Plug and Play

Plug and Play (PnP) technology provides a combination of hardware and software
support that enables a computer system to recognize and adapt to hardware
configuration changes with little or no intervention from the user.
Video capture drivers frequently lack sufficient test coverage in the following PnP-related
areas:
• Enumeration
• Installation / uninstallation
• Device enabling / re-enabling
• Plugging / unplugging: hot, warm, and cold

Enumeration can be tested functionally by running an application (such as Blink,

GraphEdit, or your own test tool) and verifying that your device is present on the bus and
working normally.
You can also verify enumeration by using Device Manager. To do this, run Devmgmt.msc
from the command line and verify that your device appears in the resulting device list.
DevCon.exe, the Device Console tool, is a command-line tool that displays detailed
information about devices and lets you search for and manipulate devices from the
command line. You can use DevCon to obtain detailed information on the device
installation process. DevCon can also help you to analyze failure cases. DevCon can
enumerate “hidden” devices and is more flexible than Device Manager.
See the "Essential Tools..." section of this paper for information on how to obtain the
Device Console tool.
You can also test enabling and re-enabling a device with Device Manager. Right-click the
device and click Disable; then right-click the device and click Enable. Alternatively, use
Device Console to disable and re-enable the device.
Since DevCon is a console application, it is possible to set up a simple batch file to
enumerate a device, disable it; try to enumerate it; enable it; and so on. Typically, a bus
reset is generated; in addition, a device that is disabled may need to reinitialize on an

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 5

enable command. These behaviors can cause device enumeration to be slow. Therefore,
such a batch file should include a command to sleep 10 seconds or pause between each
step.
You can also run a WHQL HCT test, Disabler, to run through a series of enable and
disable operations.
The INF File Syntax Checker, or ChkINF, uses a set of Perl scripts to verify the structure
and syntax of INF files for drivers designed for Microsoft Windows 2000 and later
versions of Windows. After examining a file, ChkINF lists errors and warnings relevant to
that INF file in HTML format.
Use ChkINF to verify that you have correctly formatted your INF file.
Improper handling of device plug events and unplug events is the source of a significant
portion of bugs in video capture drivers. Unplugging, also called surprise removal, is the
physical removal of an IEEE 1394 or USB device cable from the computer.
If the device is enumerated but not loaded by any application, this removal is a cold
unplug event. If the device is loaded by an application but is not running at the time of
removal—the device is in a stop state or pause state—then the event is a warm unplug
event. If the removed device is in the process of streaming when removed, the event is a
hot unplug event. Each removal type results in a different code path; be sure to test each
case separately.
Since a PCI bus device cannot be removed physically from the computer during powered
operation, you can disable and then re-enable the driver with either Device Manager or
Device Console.

Power Management
Video capture drivers frequently lack sufficient test coverage in power-management.
Power state indicates the level of power consumption—and thus the extent of computing
activity—by the system or by a single device. The Power Manager sets the power state of
the system as a whole. Device drivers set the power state of their individual devices.
The Advanced Configuration and Power Interface (ACPI) specification defines two sets of
discrete power states—system power states and device power states. Each power state
has a unique name. System power states are named Sx, where x is a state number from
the range 0 to 5. Device power states are named Dx, where x is a state number from the
range 0 to 3.
The state number is inversely related to power consumption: higher-numbered states use
less power. States S0 and D0 are the highest-powered, most functional, fully on states.
States S5 and D3 are the lowest-powered states and have the longest wake-up latency.
These clearly defined power states allow many devices from various manufacturers to
work together consistently and predictably. For example, when the Power Manager puts
the system in state S3, it relies upon drivers that support power management not only to
put their devices in the corresponding device state but also to return to the working state
in a predictable fashion.
WHQL requirements depend on the host system, but in general, test your device in S1,
S3, S4, and S5 on the same system. To test power states, use the Sleeper tool from the
Windows DDK. Sleeper replaces the obsolete Dumppo tool, which was used to test
power states in Windows 2000.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 6

An HCT tool, Blink (referred to in the HCT documentation as the "Audio or Video Capture
and Control Test"), can help with power state testing. It features both manual and
automated modes. Blink is part of the WHQL logo tests for video capture devices.
Blink can discover and cycle through all of the display video states as well as the device’s
power states.
Both Sleeper and Blink are more fully described in the “Essential Tools...” section of this
paper.

Display
Video capture drivers frequently lack sufficient test coverage in these display-related
areas:
• Fast User Switching
• Resolution changes

Fast User Switching

Fast User Switching (FUS) is a feature of Windows XP and later operating systems that
allows multiple users to be logged into the same machine simultaneously. A particular
user's desktop and any running applications persist through multiple sessions. As a
result, users who are logged in simultaneously may interact sequentially with a video
capture device or application.
Fast User Switching works by allowing multiple virtual display drivers to run at the same
time. Each virtual display driver is associated with a particular PDEV data structure. (A
PDEV is a private, driver-defined data structure that is a logical representation of a
physical device.)
The video miniport driver, however, exists as a single instance. When one of the virtual
display drivers calls a video miniport driver callback function, serious problems ensue if
the miniport driver attempts to access a passed-in memory address in the context of the
display driver when that display driver instance is no longer the active kernel thread. A
fundamental principle of the display driver architecture is that information should flow in
one direction only: from the display driver to the video miniport driver.
Fast User Switching uses Terminal Services technology and is therefore compatible with
most earlier Microsoft Win32® applications. If an application is Windows 2000 logo
compliant, it implements user profile separation and power management features; such
an application should run properly under individual Windows XP user accounts.
To learn how to enable Fast User Switching, consult Windows Help. To access Help, click
Help from the Start menu.
Once you have logged on as multiple users, test your driver and video capture application
within the separate user profiles.
Windows Installer technology supports separation of user data, user settings, and
computer settings. You can use Windows Installer to manage the installation and setup of
your application. By doing this, you can support true profile separation.
Register for Notification of a User Switch

Typically, an application does not need to be notified when a user switch occurs. If your
application must be notified of a session change, call the
WTSRegisterSessionNotification function to register to receive a
WM_WTSSESSION_CHANGE message.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 7

Be aware of other instances of your application that may be running. If your application
attempts to download an update from the Internet, the update may conflict with another
user running your application in a different session. The update can fail or disrupt other
running instances of the application. Your application should be designed to signal all
running instances of the application to save data and exit before starting a dynamic
update.

Resolution Changes
Full-screen command prompts, resolution size/color quality changes, and DirectDraw
surfaces (such as games and screen savers) may pose challenges for video playback
rendering. Verify that your driver can handle these situations.
If you force a resolution change, your application should attempt to restart playback from
the last known position.
If your application is sensitive to resolution changes, it should register for the system-wide
WM_DISPLAYCHANGE event and rebuild the filter graph if necessary.
Verify that your video capture driver works correctly with the following:
• Screen savers
• Screen lock
• Task Manager
• Full-screen command prompts

Buses and Devices

Video capture drivers frequently lack sufficient test coverage in these areas related to
buses and devices:
• Hubs
• High-speed and full-speed USB devices
• Multiple devices

Users will plug a variety of types of devices into a bus. To cover this scenario, test USB
and IEEE 1394 bus drivers with a range of devices—for example, mass storage devices,
HID devices, audio devices, and cameras.
Users may also mix full-speed USB devices with high-speed USB devices. The USB 1.1
specification supports throughput up to 12 Mbps (full-speed); the USB 2.0 specification
supports throughput up to 480 Mbps (high-speed). Accordingly, when testing hubs, plug
in a mixture of high-speed and full-speed devices simultaneously.
One possible scenario involves a high-speed camera sending digital video (DV) encoded
data over a USB 2.0 bus to a computer that records the data to a hard disk on the same
USB/1394 bus.

Multiprocessor Systems
Video capture drivers frequently lack sufficient test coverage in these areas related to
multiprocessor systems:
• Deadlocks and spinlock
• Timing issues
• Driver verifier

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 8

When choosing an operating system for multiprocessor testing, consider the following.
Intel's Hyper-Threading Technology enables a single physical processor to execute
multiple threads simultaneously, potentially providing greater throughput and improved
performance. Windows treats a hyper-threaded processor as a multi-processor system.
Windows counts physical processors for licensing; each hyper-threaded processor counts
as one physical processor but is used by Windows as two processors. Windows XP
Home Edition supports one physical processor, while Windows XP Professional supports
up to two symmetric multiprocessors.
Microsoft Windows Server™ 2003, Standard Edition supports four-way symmetric
multiprocessing (SMP). Windows Server 2003, Enterprise Edition supports servers with
up to eight processors. Windows Server 2003, Datacenter Edition supports 32-way SMP,
and also supports Hyper-Threading Technology.
In Windows XP and later, the kernel can execute on any of the processors at any time.
Your driver can be accessed from any processor, or more than one processor at a time.
Windows and the WDM driver model do most of the work to manage the multiprocessor
environment, but your device and some of its resources need to be shared. Spinlocks are
used to synchronize access to the device and shareable resources. A spinlock is a device
driver interface call through which the driver requests access to a resource and then
waits actively until it gets it—spinning in place. A deadlock occurs when two processes
are each waiting for a resource that the other process owns.
Running a series of automated tests with multiple applications on a dual processor,
hyper-threaded processor, or (best case) dual hyper-threaded processor while running
Driver Verifier will vastly increase the number of random timing related issues that help to
expose deadlocks. See the “Essential Tools…” section of this paper for more information
on Driver Verifier.

64-bit Systems
Video capture drivers frequently lack sufficient test coverage in 32-bit and 64-bit native
testing.
Microsoft encourages IHVs to test video capture drivers in a 64-bit Windows environment.
All of the multiprocessor issues mentioned previously must also be addressed on 64-bit
systems. Therefore, consider using multiprocessor systems (dual-processor systems, at
minimum) for 64-bit testing.
Microsoft recommends using native 64-bit test applications for testing 64-bit systems.
This is because native 64-bit applications do not use the Windows 32-bit on Windows 64-
bit (WoW64) compatibility layer; this compatibility layer adds a level of indirection and
may obscure test results.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 9

Essential Tools and Configuration for Video Capture

Development and Testing
This section first presents the recommended system configuration for testing video
capture drivers and then enumerates tools that you can use for testing.

Computer Configuration for a Test

To test multimedia, Microsoft recommends:
• Computer no more than one year old (as new as possible)
• Clean installation of Windows XP with Service Pack 1
• Latest Microsoft DirectX® run time (9.0b)
• USB 2.0 (high-speed, sometimes present on cards with a 1394 interface)
• 512 MB – 1 GB RAM
• 80 GB (or greater) hard drive.
• S1, S3, S4, and S5 power states supported (Use Blink or Sleeper to verify.)

Microsoft recommends testing with supported released versions of the DirectX run time.
To do this, obtain the DirectX 8.x and 9.x run times and install them on a test system
running Windows XP. You can download this software from the Microsoft DirectX Web
site.
One test option is to have a large hard drive with a master partition running Windows XP,
as well as test and data partitions. You can reformat the test and data partitions and
reinstall the operating system or restore a backup of that partition for fast testing. This
ensures that old test software, INF files, or drivers will not skew test results.

Driver Verifier
Driver Verifier is a tool included in the Windows operating system (Windows 2000 and
later) that validates a range of device driver operations. This utility is located in the
%windir%\system32 directory.
You can run Driver Verifier on all of your test and development systems for specific device
drivers. You can find documentation for Driver Verifier in the Windows DDK.

DirectX SDK Tools

The DirectX SDK includes documentation, sample code, and tools for development of
multimedia applications and devices. This kit may be downloaded free of charge from the
Microsoft DirectX Web site.

AMCap
AMCap is both a tool and a sample with full source code provided in the DirectX SDK.
The AMCap tool demonstrates the following tasks related to audio and video capture:
• Enumeration of audio and video devices
• Live preview of audio/video device output
• Capture of streaming audio/video to a file
• Display of device property pages
• Flow control of multimedia stream from the device

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 10

In DirectX 9.0 and later, AMCap supports MPEG-2 program stream input—for example,
from analog TV tuners that stream MPEG-2 content. A third-party MPEG-2 decoder
compatible with Microsoft DirectShow® is still required to decode the streams.

GraphEdit
GraphEdit is a visual tool for building filter graphs that is included in the DirectX SDK.
GraphEdit allows you to experiment with a filter graph before you write any application
code. You can load a filter graph that your application creates and verify that your
application is building the correct graph. GraphEdit also allows you to test any custom
filters you develop or use.
GraphEdit provides a visual, drag-and-drop interface that allows you to create, start,
pause, stop, and deconstruct graphs. GraphEdit shows the filters that are registered on
your computer and the registry information for each filter. You can also view the filter
property pages and the media types of pin connections.
You can create a graph using the HCT test tool Blink and then save the graph for use in
GraphEdit.

DDK Tools
The Windows Driver Development Kit (DDK) includes development kits and testing tools
for developing drivers and other kernel-mode software for the Microsoft Windows family
of operating systems. To order the DDK, go to the Microsoft Windows DDK Web site.

Sleeper
The Sleeper tool can be found in tools\acpi\sleeper. Sleeper will display the supported
power management sleep states on a computer and can put the computer into each
state. This is useful for manually testing power management requests during complex
test scenarios.

DevCon
The DevCon tool can be found in tools\devcon. Source code is included. DevCon runs
only on Windows 2000 and later. See the discussion of DevCon in the “Plug and Play”
section of this paper.

KsStudio
The new KsStudio tool can be found in tools\avstream. KsStudio is a GUI application that
can be used to build, examine, and test kernel streaming (KS) filter graphs. You can use
KsStudio to view and validate internal device topology and property sets. KsStudio also
allows you to create pins without using KsProxy.
KsStudio gives the AVStream filter driver direct access to the filter under development.
KsStudio does not use any multimedia APIs (such as DirectSound, MMSystem, or
DirectShow) and can, therefore, be used to troubleshoot problems related to these APIs.
KsStudio provides the following basic features:
• Filter factory enumeration

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 11

• Filter and pin instantiation (including graph building)

• Filter and pin profiling
• Intra-filter topology diagramming
• Pin connecting
• Property getting and setting
• Event enabling and signal indication
• Data streaming (audio and video capture only)
• Basic functionality tests

KsStudio can also construct a graphical representation of a filter graph that shows both
the pin-to-pin connections between filters and the filters' internal nodes. KsStudio is
valuable for checking the externally exposed pins and properties of any kernel streaming
(KS) driver.

UVCView
The USBView tool, UVCView.exe ships as a Windows DDK sample in the
src\wdm\usb\usbview directory.
UVCView is a diagnostic tool for the new USB Video Class hardware and sample
devices.
UVCView offers the following features:
• Ability to save logs
• Additional validation of interface and descriptor sizes and values
• Discovery and display of all device string descriptors
• Language ID details displayed for all device string descriptors
• IAD (Interface Association Descriptor, a new USB 2.0 feature) display
• Automatic logging of output to the debugger
• More details in the display
• Native IA-64 and x64 binaries, which run on Windows Server 2003 with Service
Pack 1 and Microsoft Windows Vista™ operating systems, as well as an x86 version
that runs on Windows XP, Windows Server 2003, and Windows Vista operating
systems

UVC Testing Guidelines

• Use Verifier.exe, as described in the Driver Verifier section.

• Use UVC Emulator early in your development cycle.
• Make sure that the emulation hardware that you are using supports all of the features
you want. (For example, Netchip 2270 doesn’t support isochronous transfer.)

Use UVCView for your UVC development needs.

HCT Tools
Windows Hardware Quality Labs (WHQL) supports the Microsoft Windows Logo Program
for hardware with the Windows Hardware Compatibility Test (HCT) kit, test information,
and data for hardware testing driver signing. This kit can be downloaded from the
Microsoft WHQL Web site.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 12

The Blink.exe and MSTapeTst.exe test tools can be found in the HCT\TestBin directory of
the installed HCT Test Kit. During installation, at the Custom Setup prompt, under Test
Categories select Video Capture from the Streaming Media and Broadcast Test
Categories.
Install the HCT kit and select Streaming Broadcast as the area to test.

Blink
The Blink tool was introduced in HCT 11. In HCT 12, Blink now includes interfaces for
testing node-based drivers, such as those that interact with USB Video Class:
• ITopology
• ICameraControl
• ISelector
• IVideoProcAmp
• IVideoExtensionUnit

The Audio Video Capture and Control test (Blink.exe) verifies that audio or video capture
devices (including but not limited to DV camcorders, TV tuners, and IEEE 1394 or USB
video conferencing cameras and microphones) support Windows Driver Model (WDM)
AVStream and Stream Class device drivers and DirectShow filter graph functionality.
Individual test cases verify preview, capture, and playback of audio/video obtained from
the capture device. The test also validates adherence to power management functionality
while the device is streaming and verifies the ability of the device to function during
display resolution changes.
Blink verifies that your driver uses the Microsoft DirectShow application programming
interface (API) to manipulate a capture filter in many different ways; the test verifies
return values and settings while applying stress on the system’s capture architecture.
Blink can help you test the following:
• Capture
• Preview
• Power management
• Display mode changes

Preview is the output of audio and/or video to a rendering device, such as a speaker or
display. Capture is the output of audio/video data to a file. The DirectShow API for
preview and capture is ICaptureGraphBuilder2. To perform capture, add a File Writer as
the rendering device in the graph; to perform both preview and capture, add a Smart Tee
to split the stream.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 13

Blink tests several DirectShow interfaces, including the following:

• IAMVideoProcAmp
• IAMCameraControl
• IAMVideoCompression
• IAMVideoControl
• IAMTVTuner
• IMediaControl
• IAMDroppedFrames
• IAMStreamConfig

MSTapeTst
MSTapeTst.exe now supports digital video (DV) format and internal tape device video
capture devices. DV cameras can now use either 1394 or USB Video Class.
MSTapeTst covers audio/video control (AV/C) devices including DV camcorders, 1394
MPEG camcorders and D-VHS tape devices.
The AV/C Tape Subunit Compliance test (MSTapeTst.exe) verifies that an AV/C tape
subunit meets the data transfer specifications established by the 1394 Trade Association
in the AV/C Tape Recorder/Player Subunit Specification and complies with the Microsoft
1394 video capture stack architecture.
AV/C devices stream isochronous data over the 1394 bus using the IEC-61883 protocol,
a standard communications and control interface used by 1394 audio/video devices.
These devices include DV camcorders, MPEG recorders, and D-VHS recorders. An AV/C
device can contain multiple subunits, such as tape or storage for still images. Internally,
the AV/C Tape Subunit Compliance test uses Microsoft DirectShow. The test calls various
DirectShow API functions to build and control DirectShow filter graphs and to control the
AV/C subunits.

ChkINF
See the discussion of ChkINF in the “Plug and Play” section of this paper. ChkINF can be
run from the HCT executable Testmgr.exe. ChkINF is also available in the Windows DDK.

Call to Action
• For video capture driver developers and testers: Test more extensively in the
commonly overlooked areas described in this paper.
• Use the tools provided in the Windows DDK, DirectX SDK, HCT Kits and the
Windows operating system to help produce high-quality drivers. This paper lists these
tools and where they can be obtained.
• If you have questions about developing USB Video Class drivers, send e-mail to
UVCDISC@microsoft.com.

Resources
Microsoft Windows Hardware and Driver Central
The Microsoft Windows Hardware and Driver Central (WHDC) Web site at
http://www.microsoft.com/whdc/default.mspx includes Windows Driver Development Kits

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 14

(DDKs), Windows Hardware Compatibility Test (HCT) Kits, and Windows Logo Program
requirements.

Microsoft Windows Hardware Quality Labs

The Microsoft Windows Hardware Quality Labs (WHQL) Web site at
http://www.microsoft.com/whdc/hwtest/default.mspx includes information on hardware
testing.

Microsoft Windows Driver Development Kits

The Microsoft Windows Driver Development Kit (DDK) Web site at
http://www.microsoft.com/whdc/devtools/ddk/default.mspx includes information on
ordering Windows Driver Development Kits.

Microsoft Windows DirectX

The Microsoft Windows DirectX Web site at
http://www.microsoft.com/windows/directx/default.aspx includes information on DirectX
multimedia tools for the Windows operating system.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 15

Appendix
Video Capture Functional Classifications and Definitions
Generic Functional WHQL Input Class Bus Device
Name Category HCT 12 Stream Driver Examples
Category
Analog TV Broadcast TV Tuner analog TV 1394, Analog TV
USB, receiver
PCI
Digital TV Broadcast TV Tuner digital TV 1394, Digital TV
PCI receiver
Webcam Camera Video camera UVC 1394, Simple webcam
Input / lens USB
Capture
DV (or DV Camera Video camera MSDV 1394, DV camcorder
camcorder) Input / lens (DV) USB (camera mode)
Capture
MPEG-2 Camera Video camera MSTape 1394, MPEG-2
camcorder Input / lens USB camcorder
Capture (MPEG-2) (camera mode)
Still image Camera Still Image camera 1394, Still image
camera Devices (single USB camera
frame)
DV (or DV Recorded Video DV MSTape 1394, DV camcorder
camcorder) Input / USB (tape mode)
Capture
DVD Recorded DVD MPEG-2 PCI DVD playback,
playback Playback MPEG-2
camcorder (tape
mode), D-VHS
tape player
MPEG-2 Recorded Video MPEG-2 1394, DVD playback,
camcorder Input / USB MPEG-2
Capture camcorder (tape
mode), D-VHS
tape player
D-VHS tape Recorded Video MPEG-2 1394 DVD playback,
player Input / MPEG-2
Capture camcorder (tape
mode), D-VHS
tape player
Analog A/V Pass- Video analog 1394, Analog A/V input
input device through Input / A/V USB, device
Capture PCI
MPEG-2 Pass- Video digital 1394
Set-top box through Input / MPEG-2
Capture
DV Pass- Video Device- Device- 1394 Sony DA1
converter through Input / specific specific
Capture but very but very
broad broad

The preceding table includes the following functional categories:

• Broadcast: devices supporting analog TV (SDTV, HDTV), digital TV, and FM radio
receivers
• Camera: devices that capture live video using a lens
• Recorded: devices that receive pre-recorded video or audio/video data

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 16

• Pass-through: devices that receive a wide range of A/V data types through physical
device input jacks

“WHQL Category” refers to WHQL HCT 12 and Windows Logo Program (WLP) System
and Device Requirements, version 2.2 categories for these devices.
The preceding table includes the following types of input streams:
• analog TV: NTSC, PAL, SECAM, broadcast television in SDTV (standard definition)
and HDTV (high definition)
• FM radio
• digital TV: all digital TV types
• camera lens: live video (typically a simple webcam)
• camera lens (DV): live video recorded in DV format (DV camcorder)
• camera lens (MPEG-2): live video recorded in MPEG-2 format (MPEG-2 camcorder)
• camera (single frame):Still-image, single-frame capture device (Still Image / WIA
camera)
• analog A/V: analog audio/video data (typically from VHS or analog VCR through RCA
A/V jacks)
• DV: prerecorded data in DV format (typically from a DV camcorder tape subunit)
• MPEG-2: prerecorded data in MPEG-2 format (typically from a DVD disc)

The “Class Driver” column highlights device types that have corresponding class drivers
(MSDV, MSTape, UVC).
The “Bus” column lists buses on which the device is implemented.

"Designed for Windows" Logo Program Requirements Device Definitions

The following are draft definitions for Streaming Media devices that are proposed for the
future Windows Vista logo requirements. While the definitions below may not appear in
the final release of the Windows Vista Logo Program documents, they provide a guide for
how to classify your device.

General Streaming Media Devices: Windows Compatibility

Streaming media devices consist of hardware and software that bring external multimedia
data into a computer. Multimedia includes audio/video, video, and related control service
streams, such as VBI. Audio streaming media is covered in the Audio section of the
Windows Logo Program documents.

Encoders and Decoders: Windows Compatibility

Encoders and decoders are hardware and software components that either take a
multimedia stream and encode it into a format such as MPEG or Windows Media or take
a multimedia stream and decode it from such a format. DVD playback is an example of a
decoder application.

Broadcast Receivers: Windows Compatibility

Broadcast receivers consist of hardware and software that bring cable, over-the-air
transmission, and satellite broadcast audio/video signals into a computer. Broadcast
audio/video includes FM radio; analog television (NTSC, PAL, SECAM); and digital
television (ARIB, ATSC, DVB, DSS).

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.
 Testing Windows Video Capture Drivers — 17

Video Capture Devices: Windows Compatibility

Video capture devices are cameras and A/V input devices that bring streaming
multimedia data into a computer. A/V input devices allow an external device (such as a
VCR or an analog camcorder) to connect via input jacks and then transfer the data
streamed from the external device to a computer.
Video capture devices include cameras that take live streaming audio/video and either
save the stream to the device’s storage or send it to the computer. Cameras that take
only individual still images (and not a series of streaming images) are covered in the
Windows Image Acquisition (WIA) section of the Windows Logo Program documents.

Published June 17, 2004

© 2004 Microsoft Corporation. All rights reserved.