Windows Logo Program

səhifə	34/37
tarix	18.07.2016
ölçüsü	1.03 Mb.

1 ... 29 30 31 32 33 34 35 36 37

B11.4 Video Input/Capture

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.

B11.4.1 Video Input/Capture - Windows Compatibility

B11.4.1.1 Windows compatibility and implementation notes—Video Capture

http://www.microsoft.com/hwdev/vidcap/

B11.4.1.2 Digital Video Camcorder Support

http://www.microsoft.com/hwdev/vidcap/DVCam.htm

B11.4.1.3 WDM Video Capture Overview

http://www.microsoft.com/hwdev/desinit/vidcap.htm

B11.4.2 Video Input/Capture - Industry Standards

B11.4.2.1 ATSC Digital Television Standard, Amendment No. 1

http://www.atsc.org/Standards/stan_rps.html

B11.4.2.2 AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1

http://www.1394TA.org

B11.4.3 Video Input/Capture - Quality

B11.4.3.1 SEE B11.4.4.8

B11.4.3.2 DELETED

B11.4.3.3 SEE B11.4.4.9

B11.4.3.4 SEE B11.4.4.10

B11.4.3.5 SEE B11.4.4.11

B11.4.3.6 Pass WHQL tests

See B1.3, B4.1.4.11.

Windows XP: See “Streaming Media and Broadcast” in the HCT documentation.

B11.4.4 Video Input/Capture - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 9, "Video"

B11.4.4.1 Analog video decoder such as NTSC/PAL/SECAM meets quality requirements

[VID-0215]

B11.4.4.2 Video input or capture device provides raw sampled VBI data

[VID-0224]

B11.4.4.3 DELETED

B11.4.4.4 Video input image orientation identification meets requirements

[PC99a:15.34]

B11.4.4.5 Windows Me—Requirement for IEEE 1394 camcorders

IEEE 1394 DV camcorders must implement mandatory VCR subunit commands. DV cameras must comply with the AV/C Digital Interface Command Set VCR Subunit Specification, Version 2.0.1.
[see http://www.1394TA.org]

At a minimum, the device must support VCR subunit commands labeled "mandatory" in this specification.

B11.4.4.6 Video implementation preserves source quality during playback, storage, or processing of video streams and does not adversely affect overall PC performance

[VID-0215]

B11.4.4.7 VBI data is not affected by any type of video operation the driver is performing on video frames

[VID-0224]

That is, any cropping, scaling, or frame dropping that the hardware or the driver is performing on the related video frames.

B11.4.4.8 No tearing or other artifacts (macroblocking, jaggies, and so on)

[VID-0215]

B11.4.4.9 IEEE 1394 DV camcorder implements mandatory VCR subunit commands

Digital video (DV) cameras must comply with the AV/C Digital Interface Command Set VCR Subunit Specification.

At a minimum, the device must support VCR subunit commands labeled as "mandatory" in this specification.

B11.4.4.10 Analog input supports 720 × 480 decode to 4:2:2

[VID-0215]

B11.4.4.11 Frame rate is within 0.2 percent of PAL 25.0fps or NTSC 29.97fps standard

[VID-0215.1]

B11.4.5 Video Input/Capture - FAQs

B11.4.5.1 Current video-related FAQs

See http://www.microsoft.com/winlogo/hardware/video/.

B11.4.5.2 Test Clarification

[VID-0215]

The compatibility tests for PC systems determine whether there is excessive cross color, hanging dots, or other artifacts that could degrade the viewer experience. A DVD player with the Joe Kane Video Essentials disk with the Snell and Wilcox Zone plate test pattern is used to assess the video quality.

FAQ Date: November 27, 1998

B11.4.R Video Input/Capture - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/video/.

B12.0 Miscellaneous

B12.1 Multifunction Devices

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All requirements for each specific device class implemented in the multifunction device are included by reference.

B12.1.1 Multifunction Devices - Windows Compatibility

B12.1.1.1 Device drivers comply with Windows DDK requirements for its operating system

Third-party applications implemented as defined in the Microsoft Platform SDK.

Windows XP/Windows 2000/Windows Me: “Driver Requirements for Multifunction Devices,” “System-Supplied Setup Classes,” “INF DDInstall.HW Section,” and “MFCARD_DES” in the Windows DDK.

Windows 98: “Driver Requirements for Multifunction Devices” in the Windows Me DDK.

B12.1.1.2 Windows compatibility and implementation notes—multifunction devices

http://www.microsoft.com/hwdev/mf/

B12.1.1.3 Windows compatibility and implementation notes per bus and device class

See B1.0 and B2.0.

B12.1.1.4 Designing Multifunction Devices for Windows Operating Systems

http://www.microsoft.com/hwdev/mf/download/mfdesign10.zip

B12.1.2 Multifunction Devices - Industry Standards

B12.1.2.1 SEE related industry standards for each device class implemented on the multi-function device

See B1.0 and B2.0.

B12.1.3 Multifunction Devices - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
Chapter 22: Driver Quality Test Specification
Plus technology-specific test specifications

B12.1.3.1 - B12.1.3.4 SEE B12.1.4.2

B12.1.3.5 Pass WHQL tests

See B1.3.

Windows XP: See “Multifunction” in the HCT documentation.

B12.1.4 Multifunction Devices - Windows Experience

Design Guideline References:
PC 2001 System Design Guide: SYS-0032
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 3

B12.1.4.1 Separate drivers are required for separate functions with no start order dependencies between separate function drivers

[SYS-0032; SDG3:13]

The operating system must be able to configure and manage functions in any order, so no function on a multifunction device can depend on another function to be started before the function can be started by the operating system.

B12.1.4.2 MFP devices correctly implement driver and Plug and Play support

[SYS-0032]

Functional units on a multifunction device do not have start-order dependencies.
Resource requirements of one functional unit are not expressed in terms of another functional unit.
Operation of one functional unit do not affect or interfere with the operation of another functional unit on the multifunction device or on the system as a whole.
Each functional unit is enumerated and its resource requirements communicated to the operating system, so Windows can load the necessary drivers and assign resources to the different units in any order.

B12.1.4.3 Each independent function can be used concurrently, with no hidden dependencies

[SYS-0032]

Separate functional units must be able to operate concurrently, without interfering with each other or with other devices on the system.

B12.1.4.4 Each function can be power managed independently

[SYS-0032]

Each functional unit in a multifunction device must separately meet the power management device class specifications for its device class and be independently power managed. Each functional unit must be able to successfully complete a system sleep/wake transition (where the unit transitions from D0 to D3 to D0) without losing functionality and without requiring user intervention to restore functionality. All functional units on PCI devices that support wakeup capabilities must correctly support wake from D3cold.

B12.1.5 Multifunction Devices - FAQs

B12.1.5.1 Current general FAQs

See http://www.microsoft.com/winlogo/hardware/MF/.

B12.1.5.2 Resource requirements for MFD [Logo Program Clarification]

The PC 99 exception for multifunction PCI devices that use only a single set of relocatable resources refers solely to multifunction devices of the same device class. If different functions within a multiple-function device require separate class drivers—for example, a combination PCI network adapter and modem—then each function must provide a unique PCI SID and SVID that will allow the proper driver to be loaded for each separate function.

Multifunction devices that contain functions from separate classes will not be properly recognized during an operating system upgrade—and therefore drivers will not be properly upgraded—unless unique IDs are provided for each device.

Note that a "supervisory" driver that loads different drivers for the individual functions does not work well with Windows. In particular, driver support is likely to be lost in cases of operating system re-installation or upgrade, or with distribution of new drivers via Windows Update. Therefore, these supervisory drivers should be avoided. The Logo Program requires separate drivers for separate functions.
FAQ Date: May 28, 1999

B12.1.5.3 Exceptions to individual ID requirement for MF devices [Logo Program Clarification]

Multiple devices of the same device class, such as a multiline serial device.
Dependent video devices, such as a graphics accelerator on a video card.
Devices that are generated by an accelerator or auxiliary processor and that do not have independent hardware I/O. That processor must have an ID; under Windows XP/Windows 2000, Mf.sys must be used to enumerate the dependent devices.
FAQ Date: May 28, 1999

B12.1.R Multifunction Devices - Future Requirements

Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/MF/.

B12.1.R.1 MFP devices using USB connectivity must appear as part of a composite device

Future requirements for USB connected multifunction print (MFP) device drivers supporting composite implementations are posted at "Multifunction Print Device Design Guidelines" at http://www.microsoft.com/hwdev/mf/mfp.htm.

B12.1.R.2 DELETED

B12.1.R.3 MFP device provides legacy-free interfaces

Future requirement - Legacy interfaces such as parallel (IEEE 1284) or serial are not allowed.

1 ... 29 30 31 32 33 34 35 36 37