CN101552886A - 简化视频再现器与图形设备驱动器之间的交互作用 - Google Patents

Abstract

简化交互作用可以通过通信协议和/或API来完成，该协议和APIs允许与相关图形硬件的图形处理能力有关的将要在图形设备驱动器和视频显示之间交换的信息。在第一个典型的媒体实施例中，其中用于视频再现器的电子可执行指令促成操作包括：从一个视频显示产生一个指向图形设备驱动器的查询，这个查询请求关于处理放大(ProcAmp)能力的信息；在视频再现器上接收一个来自图形设备驱动器的响应，这个响应包括关于ProcAmp能力的被请求的信息。在第二个典型媒体实施例中，一个图形设备驱动器促成操作包括：在图形设备驱动器上接收一个来自视频再现器的查询，这个查询请求关于ProcAmp能力的信息；从图形设备驱动器向视频再现器发送一个响应，这个响应包括关于ProcAmp能力的被请求的信息。

Description

简化视频再现器与图形设备驱动器之间的交互作用

本申请是申请日为2003.04.15，申请号为03136766.6，名为“简化视频再现器与图形设备驱动器之间的交互作用”申请的分案申请。

相关的专利申请

这篇美国非临时申请专利特许证要求享有优先权，在此引入作为参考完全公开的，共同未决的美国临时申请专利特许证号为60/413,060，在2002年9月24日公开的名为“Methods for hardware accelerating the‘procAmp’Adjustments ofVideo Images on a Computer Display”。

这篇美国非临时申请专利特许证还要求享有优先权，在此引入作为参考完全公开的，共同未决的美国临时申请专利特许证号为60/376,880，在2002年4月15日公开的名为“Methods and apparatuses for facilitating De-interlacing of VideoImages”。

这篇美国非临时申请专利特许证涉及主题为美国非专利申请专利特许证号为10/273,505，在2002年10月18日公开的名为“视频再现器Methods AndApparatuses For Facilitating Processing Of Interlaced Video Images For ProgressiveVideo Displays”。这个美国非临时申请专利特许证号为10/273,505的专利也在此完全引入作为参考。

技术领域

本公开通常涉及处理用于显示的图像/图形数据，特别是，作为举例但不仅限于此，即在视频显示与图形设备驱动器之间使用一个通信信息协议来简化他们之间的交互作用，以及随之出现的功能性。这种信息可以包括查询、响应、指令等等，它们被发往例如ProcAmp调节操作。

背景

在一个典型的计算机环境中，一块图形卡或者类似的设备能够传输图像到一个显示设备上和用于管理至少部分的图像处理。对于视频图像，经常需要图形卡和全部的计算机设备使用一种图形覆盖设备和技术。例如，为了显示来自于一个DVD或者因特网流媒体源的视频图像，需要启动一个图形覆盖程序来放置和维持视频图像。

一个图形覆盖程序选择一个长方形和一个基色用于建立视频图像将被显示的屏幕位置。对于一个长方形的角连同期望的高度与宽度一起，一个长方形可以定义一个起始坐标。基色通常是一种很少看到的颜色，例如明亮的粉红色，用于确保视频被覆盖在定义的长方形内部，除非视频被逻辑的定位在一个显示屏桌面的最上层。

在操作中，因为图形卡向一个显示设备提供像素颜色，它检查以确定一个给出的像素位置是否在挑选的图形覆盖长方形内。如果不是，默认的图像数据被发往显示设备。另一方面，如果给出的像素位置在挑选的图像覆盖长方形内，图形卡会检查确定那个像素的默认图像数据是否与挑选的基色相同。如果不同，对于给出的像素，默认的数据图像被发往显示设备。另一方面，如果给出像素的颜色就是选定的基色，对于那个给出的像素，图形卡将视频图像数据发往显示设备。

不幸的是这种图形覆盖技术有几个缺点。第一，通常只有具有充足的硬件资源，才能对于一个图形覆盖程序在任何一次都是有效的。无论如何，依靠图形覆盖技术总是由于受到硬件上的限制而导致可能同时进行视频显示的数量上的限制。第二，当包含被显示视频的窗口在显示屏幕的桌面周围被有力地移动时，粉红色或者其他基色有时会成为可见的(例如在一个相关的显示设备上显示)。

第三，因为在显示设备上显示的视频图像没有被打印屏幕命令捕获，一个打印屏幕命令同样不会有效地起作用。代替的，基色被打印屏幕命令捕获到，因此打印出的(或者被复制的和被粘贴的)图像包括一个基色的实心长方形，在这里视频显示在显示设备上。

另一种用于显示视频图像的技术需要使用主机的微处理器在传输的图形处理器的视频图像发到到显示设备之前进行视频调节。这种主机处理器技术也有几个缺点。第一，一个典型计算机环境的主机微处理器和相关的内存子系统没有针对大型视频图像进行优化。因此，可以显示的视频图像的大小和数量被严格的限制。第二，为了主机的微处理器有效的工作，视频图像一定要驻留在主机微处理器可以直接寻址的内存里。结果，其他类型的硬件加速，例如解压缩和/或去隔行，都不能在视频图像上执行。

简而言之，前面的技术，例如图形覆盖程序和依靠微处理器，都导致了视觉的假象，太慢和/或不能有效地利用内存，受硬件限制，抑制视频显示的灵活性，和/或不能使用一个全功能的打印屏幕命令。因此，需要有一个方案和/或方法来补救这些和那些的不足，特别是来简化视频再现器与图形设备驱动器之间的交互作用。

概述

简化视频再现器与图形设备驱动之间的交互作用可以通过通信协议和/或应用程序接口(APIs)来进行，应用程序接口允许与相关图形硬件的图像处理能力有关的信息在一个图形设备驱动器和一个视频再现器之间交换。图像处理能力包括视频处理能力；作为例子但是不仅限于此，视频处理能力包括处理放大(ProcAmp)控制调节，去隔行，屏幕高宽比校正，颜色空间转换，帧速率转换，垂直或者水平反映和alpha混合。

在一个典型的方法实施例中，一个方法简化一个或者多个视频再现器和至少一个图形设备驱动器之间的交换作用，这个方法包括由一个或者多个视频再现器的一个视频显示发出查询动作，至少一个上述图形设备驱动器与视频处理能力有关；通过至少一个图形设备驱动器，通知视频再现器至少一个图形设备驱动器可以提供给视频再现器的视频处理能力的至少一个子集。

在第一个典型的媒体实施例中，一个视频显示中的电子可执行指令做出的动作包括：从一个视频显示向一个图形设备驱动器发出查询，这个查询请求信息涉及ProcAmp能力；从图形设备驱动器接收一个视频显示的响应，这个响应包括与ProcAmp能力有关的被请求的信息。

在第二个典型的媒体实施例中，一个图形设备驱动器中的电子可执行指令做出的动作包括：从一个视频发生器接收一个图形设备驱动器的查询，这个查询请求是与ProcAmp能力有关的信息；同时从图形设备驱动器向视频发生器发出一个响应，这个响应包括与ProcAmp能力有关的被请求信息。

在一个典型的系统实施例中，一个系统简化视频再现器与图形设备驱动器之间的交互作用，这个系统包括：适合准备查询的视频显示逻辑，这个查询请求涉及可以提供给将要显示视频的处理放大(ProcAmp)能力的信息；适合准备响应的图形设备驱动逻辑，这些响应指出可以提供给将要显示视频的ProcAmp能力。

其他方法，系统，设备，协议，媒体，配置等等的实施例在这里描述。

附图的简要描述

在整个附图中涉及相似的和/或相应的各个方面，特征和元件使用相同的数字。

图1是包括一个ProcAmp调节操作的第一个视频处理流程图流程图。

图2是包括到达一个RGB渲染目标的两个视频处理操作的第二个视频处理流程图。

图3是包括到达一个RGB渲染目标的一个视频处理操作的第三个视频处理流程图。

图4是一个结构图，它举例说明配置用于简化视频再现器与图形设备驱动器之间的交互作用的一个计算机或者其他电子设备的某些的功能部件。

图5是一个通信/信号图，它举例说明一个视频再现器和一个图形设备驱动器之间的一个典型协议。

图6是一个流程图，它举例说明一个简化视频再现器和一个图形设备驱动器之间的交互作用的一个典型的方法。

图7举例说明能够(全部的或者部分的)实现这里描述的简化视频再现器与图形设备驱动器之间的交互作用的至少一方面的一个典型计算(或者一般的电子设备)运行环境。

详细描述

典型的视频处理流程图和ProcAmp调节

具有一个ProcAmp调节的典型视频处理流程图

图1是包括一个ProcAmp调节操作104的第一个视频处理流程图100。第一个视频处理流程图100可以使用图形硬件例如一个图形卡来实现。它包括(i)三个图像内存方框102，106和108，和(ii)至少一个图像处理操作104。图像内存方框102包括一个YUV视频图像画面外普通平面。包含一个举例说明的ProcAmp调节操作104的图形处理操作104被应用到图像内存方框102来产生图像内存框106。图像内存框106包括一个YUV画面外普通平面或者一个YUV结构，它依赖于参数和执行图像调节操作的图形硬件的能力。

在一个或者更多附加的图像处理操作后(没有在图1中明确的表示)，图形硬件产生图像内存方框108，它包括一个RGB渲染目标。图像内存方框108的RGB渲染目标可以通过图形硬件在一个显示设备显示，而不用额外的图像处理操作。而且图像内存方框108包括一个显示设备的屏幕的每个像素的图像数据，以至于在图像数据从图像内存方框108转发到显示设备时不需要从其他的内存收回图像数据。

ProcAmp调节操作104涉及到一个或者更多的处理放大(ProcAmp)调节。ProcAmp调节概念起源于视频被存储、操作和显示的时使用的模拟技术。但是，现在可以使用数字技术执行ProcAmp调节操作104。这种ProcAmp调节操作104可以包括一个或者更多的操作，它们被指向至少下面的视频特性中的一个或者几个：明亮度、对比度、饱和度和色调。

典型的ProcAmp相关视频特性

明亮度、对比度、饱和度和色调的随后的描述，连同用于操作他们的值的可能的和/或建议的设置，是用于一个典型的描述性实施例。其他的ProcAmp调节准则可以选择地使用。

明亮度：明亮度也被认为是“黑设置”；明亮度不能与增益(对比度)相混淆。它被用于在每一个特别的观看情况下设置‘观看黑色’的级别。功能上地它从一幅画面的所有亮度字中增加或者减少量化步骤(比特)的相同数量。如果偏移加上一些亮度亮度字小于0或者大于全范围，它能够而且通常创建剪辑的情况。它通常与对比度控制交互作用。

对比度：对比度是图画亮度的‘增益’。它是用于更改画面的相关的亮到暗的数值。功能上它是一个线性的正或负的增益，即将数值的输入范围映射到一个更小或者更大的范围。设置点(举例来说，当增益变化时没有改变)通常等于一个代码0，但是更适当地这个代码字与一个标称的观看黑色设置点有关。对比度增益结构通常是一个通过这个设置点的线性的传输斜面。如果设置的增益不是1对1的，对比度功能通常包括计算的数值的舍入，舍入通常包括计划性的抖动来避免可视的假象‘造型’的产生。

饱和度：饱和度是对比度的逻辑当量。它是一个增益功能，带有围绕一个“零色度”的设置点(例如，在描述的实施例中的YUV上的代码128或者RGB上的代码0)。

色调：色调是色度成分的一个相位关系。色调典型地以级别来表示，具有一个从-180到+180的可用范围和一个默认的0级别。成分系统(例如，YUV或者RGB)中的色调是一个三部分的变量，其中三个成分一起变化以便维持可用的色度/亮度关系。

在YUV颜色空间中的典型的ProcAmp相关调节

下面的用于在YUV颜色空间内处理明亮度、对比度、饱和度和色调的描述连同用于操作他们的值的可能的和/或建议的设置是用于一个典型的描述实施例。其他的ProcAmp调节准则可以选择地使用。一般地，在YUV颜色空间的工作简化了用于一个视频流的ProcAmp调节控制包括的计算。

Y处理：从Y值中减去16用来将黑色级别定位在0。这样去掉了DC的偏移以至于调节对比度不会改变黑色级别。因为Y值可以小于16，负的Y值应该在处理中的这个点被支持。对比度通过将YUV像素值乘以一个常数调节。(如果U和V被调节，无论什么时候改变对比度都会导致一个颜色的偏移)。从对比度调节的Y值添加(或者减少)明亮度特性值，这阻止由于对比度调节而产生的DC的偏移。最后，将16加回来重新将黑色级别定位在16。一个用于Y值处理的典型公式是这样的：

Y’＝((Y-16)×C)+B+16

这里C是对比度值，B是明亮度值。

UV处理：首先从U和V中减去128来将范围定位在0周围。单独的色调特性通过像下面一样将U值和V值混合在一起来实现：

U’＝(U-128)×Cos(H)+(V-128)×Sin(H)，和

V’＝(V-128)×Cos(H)-(U-128)×Sin(H)，

这里H代表所需的色调角度。

饱和度通过将U和V都乘以一个与饱和度值在一起的常数来调节。最后，数值128被加回到U和V。在UV数据上的色调和饱和度的组合处理是这样的：

U’＝(((U-128)×Cos(H)+(V-128)×Sin(H))×C×S)+128，

和

V’＝(((V-128)×Cos(H)-(U-128)×Sin(H))×C×S)+128，

这里C是上面的Y’公式中的对比度值，H是色调角度，S是饱和度。

具有两个处理操作的典型视频处理流程图

图2是包括到达一个RGB渲染目标108的两个视频处理操作202和206的第二个视频处理流程图200。第二个视频处理流程图200包括(i)三个图像内存方框102，204和108，和(ii)两个图像处理操作202和206。

一般地对于第二个视频处理流程图，图像内存方框包括一个RGB纹理。图像内存方框204由图像内存方框102在图像处理操作202应用程序后产生。图像内存方框108由图像内存方框204在图像处理操作206应用程序后产生。

其他图像处理操作，加上一个ProcAmp控制调节可以被实现。例如，下面任何一个或者更多的典型视频处理操作可以在这些数据被显示在一个显示设备的屏幕上之前提供给视频图像数据：

1.ProcAmp控制调节

2.去隔行

3.屏幕高宽比校正

4.颜色空间转换

5.垂直或者水平反映和alpha混合

在可能的时候，所需的视频(和/或其他图像)处理操作被组合成尽可能少的操作，以便减少处理视频图像时消耗的全部的内存带宽。处理操作可以被组合到的级别一般取决于图形硬件的性能。典型地，颜色空间转换处理和屏幕高宽比校正操作被应用到很多的视频流，否则就是最多。可是，垂直或者水平反映和alpha混合不被频繁的应用。

对于第二个视频处理流程图200，ProcAmp调节处理和颜色空间转换处理被组合到图像处理操作202。屏幕高宽比校正和图像处理操作206被执行。可选地，垂直或者水平反映和/或alpha混合可以被组合到图像处理操作206。正如被描述的，实现第二个视频流程图200的图形硬件使用两个图像处理操作和三个图像内存块来产生图像内存块108作为RGB渲染目标。可是，某些图形硬件可以更有效。

具有一个处理操作的典型视频处理流程图

图3是包括到达一个RGB渲染目标108的一个视频处理操作302的第三个视频处理流程图300。一般地，第三个视频处理流程图300通过使用一个图像处理操作302和两个图像内存方框102和108的图形硬件来实现。特别地，图像内存方框108通过图像处理操作302由图像内存方框102产生。正如所描述的，图像处理操作302包括下面描述的多个视频处理操作。

第三个视频处理流程图300比第二个视频处理流程图200(图2)更短，因为图像处理操作302结合了ProcAmp调节处理，颜色空间转换处理和屏幕高宽比校正处理。因此一个给出的视频处理流程图中的步骤的数目由显示视频图像的软件(例如，一个应用程序，一个操作系统的成分等等)和相关的图形硬件一起请求的图像处理操作的数目和类型来决定。典型的软件，图形硬件等等在下面参考图4作进一步描述。

典型的视频相关软件和图形硬件

图4是一个结构图400，它举例说明配置用于简化视频再现器视频再现器410与图形设备驱动器422之间的交互作用的一个计算的某些功能性元件或者其他电子设备。这些多样的典型元件和/或功能在硬件，软件，固件和一些其中的组合等等中可以实现。参照本文的描述，这些硬件，软件，固件和一些其中的组合等等逻辑上可以是组合的和分离的。

结构图400的配置只是一个视频数据处理设备或者系统的一个例子。应该理解为，描述的和描写的元件和/或功能的一个或者更多可以组合、调整、增加、省略等等，而不会损害简化视频再现器与图形设备驱动器之间的交互作用的能力。

设备或者系统400包括转换逻辑408，例如它可以包括由一个中央处理单元(CPU)，一个图形处理单元和/或其中的一个组合执行的指令。转换逻辑408被配置为从至少一个源406接收编码的视频数据。来自源406的编码的视频数据以一些方式被编码(例如MPEG-2等等)，转换逻辑408被配置为解码这些编码的视频数据。

作为例子，源406可以包括一个磁盘和有关的磁盘驱动器，一个光盘和有关的圆盘驱动器，一个磁带和有关的磁带驱动器，固态内存，一个被传输的信号，一个传送媒体，或者其它的被配置为递送或者另外地将编码的视频数据提供给转换逻辑408的相似的源。源406的附加的例子在下面参考图7进行描述。在一般的实施例中，资406可以包括多种的源部分，例如一个网络源和远程源。正如所描述的，源406包括因特网404和一个远程基于磁盘的存储器402。

被转换逻辑408输出的解码的视频数据被提供给至少一个视频再现器视频再现器410。作为例子但不仅限与此，可以使用Microsoft Windows操作系统(OS)的视频混合器和显示器(VMR)来实现视频再现器视频再现器410。在描述的实施例中，视频再现器视频再现器410被配置为在解码视频流中帮助转换逻辑408，来促成要被执行的视频处理操作，来混合任何其他的辅助的图像数据，例如闭路字幕(CCs)或者带有视频图像的DVD子画面图像等等。在适当的时间，对于在一个显示设备436上的可能显示，视频再现器视频再现器410提交或者促成视频图像数据到图形接口逻辑412。

因而，得到的翻译出的视频数据被提供给图形接口逻辑412。作为例子但不仅限于此，图形接口逻辑412可以包括例如DirectDraw，Direct3D，和/或其他类似的逻辑。图形接口逻辑412被配置为在视频再现器视频再现器410与图形设备424之间提供一个接口。正如所描述的，图形设备424包括一个图形处理器单元(GPU)426，一个视频内存432，和一个数字到模拟转换器(DAC)434。作为例子但不仅限于此，图形设备424可以作为一个被配置在计算或者其它电子设备内部的视频图形卡来实现。

图形接口逻辑412输出的图像数据使用一个设备驱动器接口(DDI)414被提供给一个图形设备驱动器422。在图3中，设备驱动器接口414被描述为其至少具有一个应用程序接口(API)。设备驱动器接口414被配置为支持和/或建立在视频再现器视频再现器410和图形设备驱动器422之间的接口。

正如在设备/系统400中所描述的，对于一个描述的实施例，设备驱动器接口414和图形设备驱动器422可以进一步被分类为关于相关操作系统环境和图形设备424的一个用户模式418或者一个核心模式420的一部分。因此，视频再现器视频再现器410和设备驱动器接口414是用户模式418的一部分，图形设备驱动器422是核心模式420的一部分。那些至少发生在设备驱动器接口414和图形设备驱动器422之间的通信交叉在用户模式418和核心模式420之间。

在这个描述的实施例中，视频再现器视频再现器410输出的视频图象数据就是这样提供给图形处理器单元426的。图形处理器单元426被配置为执行一个或者更多的图像处理操作。这些图像处理操作包括ProcAmp调节和/或其他的分别由ProcAmp调节逻辑428和/或其他视频处理操作逻辑430所指出的视频处理操作。ProcAmp调节操作和其他的典型视频处理操作，例如去隔行和帧速率转换，像上面一样将在下面作进一步的描述。

来自图形处理器单元426的输出被提供给视频内存432。当视频内存432被读取时，产生的图像数据可以被发送到一个数模转换器434，转换器输出一个适合被显示设备436显示的模拟视频信号。在其他的配置中，显示设备436能够显示来自视频内存432的数字图像数据，而不用一个数模拟转换器434的模拟转换。

在一个视频再现器和一个图形设备驱动器之间的典型协议

图5是一个通信/信令图表500，它举例说明一个视频再现器视频再现器410和一个图形设备驱动器422之间的一个典型协议。典型协议优化像ProcAmp调节一样的视频(或者其他图像)处理操作的性能。这样的视频处理操作可以包括那些被一个用户请求/指定的被激活和被控制的视频显示应用程序(例如一个策划应用程序)。

通信/信令图表500包括在视频再现器视频再现器410和图形设备驱动器422之间的多个信息交流和通信传输。可选地，通过图形接口412(图4中的)和/或设备驱动器接口414，可以打开和/或帮助这些通信通过图形接口412(图4中的)和/或设备驱动器接口414，和其中的任何可应用的API。

一个信息交流502被发送来确定视频处理(VP)能力。特别地，在传送502A中视频再现器视频再现器410请求或者查询图形设备驱动器422关于被图形设备驱动器422处理和提供的视频处理能力。响应502B，图形设备驱动器422告知视频再现器被分配的视频处理能力。

被分配的视频处理能力包括那些视频设备驱动器422能够执行的视频处理操作。这些可以包括ProcAmp控制调节，去隔行操作，屏幕高宽比校正，颜色空间转换，垂直或者水平反映和alpha混，帧速率转换等等中的一个或者更多。图形设备驱动器422可以选择提供剩余的视频处理操作带宽的全部或者一部分。通过分配小于全部的剩余视频处理操作带宽，图形设备驱动器能够对于后面的请求保持预留额外的视频处理操作带宽。

一个信息交流504被发送来确定控制特性能力用于一个指定的视频处理操作。在一个从视频再现器视频再现器410发到图形设备驱动器422的一个请求504A中，视频再现器视频再现器410指定了一个分配在响应502B中的特别的视频处理操作。请求504A也可以包括一个质询，为了使图形设备驱动器422能够执行关于特别的视频处理操作的什么能力或者哪一种特性能力。在响应504B中，图形设备驱动器通知视频再现器视频再现器410对于这种特别的视频处理操作可用的特性能力。例如，如果对于特别的视频处理操作没有多个控制特性能力，信息交流504可以被忽略。

一个信息交流506被发送来确定其他分配的视频处理操作中的哪一个可以与指定的特别视频处理操作同时执行。在请求506A中，如果需要，视频再现器视频再现器410向图形设备驱动器422发出一个查询来确定哪一种视频处理操作可以与特定的视频处理操作同时执行。图形设备驱动器422在响应506B中告知视频再现器视频再现器410对于图形设备驱动器422来说可能与特定的视频处理操作同时执行的视频处理操作。作为例子但不仅限于此，它应该注意(i)传送504A与506A和/或(ii)传送504B与506B可以分别地被结合到单一的查询和响应传送中。

一个信息交流508被发送来确定用于特别的视频处理操作的指定的控制特性的数值。在请求508A中，视频再现器视频再现器410在一个质询中对于特别的视频处理操作指定了一个控制特性。指定的控制特性可以从响应504B中提供的可用的控制特性中选择。图形设备驱动器422向视频再现器视频再现器410提供一个与用于特别的视频处理操作的指定控制特性有关的数值。这些值可以是数字的设置点、范围等等，视频再现器视频再现器410可以在命令图形设备驱动器422执行特别的视频处理操作的时候利用它作为一个帧网络。对于在响应504B中指出的每一个可用的控制特性，信息交流508可以被重复。可选地，一个这样的信息交流508可以被发起到可用的控制特性的多个(包括所有)控制特性。

一个信息交流510被发送来初始一个视频处理流对象。在指令510A中，视频再现器视频再现器410发出一个命令到视频设备驱动器422来打开一个视频处理流对象。这个命令可以被发射，它代表设法在显示设备436上显示视频图像的一个应用程序或者其他的软件部分。在响应510B中，图形设备驱动器422向请求的视频再现器视频再现器410返回用于视频处理流对象的一个处理。

在传递512A中，视频再现器视频再现器410命令图形设备驱动器422执行特别的或者其它的被分配的视频处理操作。执行视频处理操作的命令包括可以选择将要设置的数值和/或改变用于特别的视频处理操作的一个或者更多的控制特性的数值。在响应中，图形设备驱动器422正像在传递512A中请求一样执行了一个视频处理操作512B。典型地，至少一个视频再现器再现器410被分配到将要显示视频的每一个应用程序。无论何时这样一个发起的应用程序都会请求一个视频处理操作，例如可选地在重新格式化、转换等等之后，视频再现器再现器410发送这样的请求到图形设备驱动器422作为一个视频处理操作指令。

当视频处理流对象还存在的时候，执行视频处理操作命令512A和得到的视频处理操作512B可以根据需要重复使用。当视频被完成或者相关的软件终止后，一个关闭视频处理流对象指令514会被从视频再现器再现器410传送到图形设备驱动器422。

例如，图4，5和6的方法在被分为多个结构和/或多次传递的图表中作了描述。但是，这些方法被描述和/或表示的顺序和/或布局并不意味着被认为是一个限制，为了优化视频再现器再现器和图形设备驱动器之间的交互作用，可以组合和/或重新安排任何数量的结构/传递在任何顺序来实现一个或更多系统、方法、媒体、协议、配置等等。此外，虽然这里的描述包括对于例如像图4(还有图7中的典型系统环境)的特别实施例和典型API的参考，但是这些方法可以在任何适合的硬件，软件，固件或者其中的组合中实现和使用任何适合的编程语言、编码机制，协议范例，图形设置等等。

典型的通用API实施例

图6是一个流程图600，它举例说明一个简化视频再现器再现器和一个图形设备驱动器之间的交互作用的一个典型的方法。虽然像图6所反映的描述的实施例被发送到ProcAmp调节操作，但是不是这样限制的。代替的是，至少这个典型的通用API实施例的每一个方面可以和一个或者更多其它视频(或者一般的图像)处理操作一起使用。

在流程图600中，视频再现器410与9个方框602-618有关，图形设备驱动器422与6个方框620-630有关。方框602-618和620-630中的每一个都分别地对应由视频再现器视频再现器410和图形设备驱动器422执行或者代表它们的至少一个操作。

流程图600在下面的典型通用API的上下文中描述。这里描述的这些通用的API被分为两种方法、设备逻辑等等的功能组。第一个组可以被用来确定图形设备的视频处理能力。第二个组可以被用来创建和使用视频处理操作流对象。

这些典型的通用API可以对应的被描述为设备驱动器接口414的一部分的API 416(图4)，它支持图形接口412，而且对接图形设备驱动器422。API 416被描述为在用户模式部分418下的设备驱动器接口414的一部分。可是，这样的API 416可以更改地被定位于设备驱动器接口414的和/或作用于设备驱动器接口414之外的其他逻辑。仅仅作为例子，这种其它的逻辑包括视频再现器410，图形接口412，核心模式部分420的一部分等等。

在这段中下面描述的通用的API可以被用来扩展/增强/等等。例如，MicrosoftDirectX视频加速器(VA)是为了支持许多视频处理操作(例如，ProcAmp调节，帧速率转换等等)中的任何一个，这些操作用于与图形设备驱动器一起被显示的视频内容中。额外的相关信息可以在2001年1月23日的Microsoft Windows平台设计记录中被题名为“DirectX VA：Video Acceleration API/DDI”的书中找到。因此“DirectX VA：Video Acceleration API/DDI”通过参考被包括在这里的总体中。

虽然这里按照API描述的流程图600的动作被特别的应用到个人电脑的Microsoft Windows操作系统的目前的进展中，但是应该懂得其中的方框和这里描述的其它实施例也适用于其它的操作系统和/或其它的电子设备。

在下面的例子中，视频处理操作的输出被提供在一个RGB渲染目标格式中，例如一个目标DirectDraw表面。这样做可以排除传统的硬件覆盖技术的需要。额外地，在一个显示设备上可以看到的整个屏幕，包括任何视频图像，存在且进一步显示在一个内存位置以至于它可以被一个打印屏幕命令捕获到。这个打印屏幕的捕获然后可以被粘贴到一个文档中，添加到一个文件中，直接打印等等。

在流程图600中，依下列各项，视频再现器再现器410可能已经被图形设备驱动器422通知相关硬件能够执行ProcAmp调节视频处理操作或者视频再现器视频再现器410可以确定ProcAmp能力的存在或者缺乏。在方框602中，视频再现器视频再现器410提供一个要被显示的视频的描述，请求关于ProcAmp控制属性的图形处理能力。

视频再现器视频再现器410进行视频描述的准备和/或到图形设备驱动器422的控制属性请求，通过在方框602和方框620之间的传递箭头指出的一个或者多个传递。视频描述使得图形设备驱动器来改变成可用/可能/等等。视频处理能力基于视频的类型。例如，可以对于几个不同类型视频中的每一个设立一个预定装置。

在方框620中，视频设备驱动器422向视频再现器视频再现器410提供一个可用的ProcAmp控制属性列表。这个列表可以包括零或一个或者多个明亮度，对比度，饱和度和色调。在方框604中，视频再现器视频再现器410从图形设备驱动器422接收到可用的ProcAmp控制属性。可以执行方框620和622的动作来响应方框602的通信。可选地，视频再现器视频再现器410可以执行一个个别的查询来引起方框22的操作。

在方框622，图形设备驱动器422向视频再现器视频再现器410提供那些可能与ProcAmp调节操作同时/并行执行的视频处理操作。这样的视频处理操作可以包括零或一个或者多个YUV2RGB，拉宽X，拉宽Y，子矩形和AlphaBlend。其他这样的操作可以包括去隔行，帧速率转换等等。在方框606，视频再现器视频再现器410从图形设备驱动器422接收可能的同步视频处理操作。

一种用于实现框602、604、606、620的至少部分操作的典型通用APT依下列各项提供：

ProcAmpControlQueryCap

这个API允许视频再现器视频再现器410询问图形设备驱动器422来确定关于一个ProcAmp控制设备和任何可能在同一时间正在执行的ProcAmp调节操作所支持的额外的处理操作信息。

HRESULT

ProcAmpControlQueryCaps(

[in]DXVA_VideoDesc*lpVideoDescription，

[out]DXVA_ProcAmpControlCaps*lpProcAmpCaps

)；

图形设备驱动器报告用于这种模式的它的能力，即用于lpProcAmpCaps的一个输出DXVA_ProcAmpControlCaps中的能力。

typedef struct_DXVA_ProcAmpControlCaps{

DWORD Size；

DWORD InputPool；

D3DFORMAT OutputFrameFormat；

DWORD ProcAmpControlProps；

DWORD VideoProcessing Caps；

}DXVA_ProcAmpControlCaps；

Size区域指出数据结构的大小，在其他情况中如果不同的版本具有不同的数据结构，它还可以被作为一个版本指示器。

InputPool区域指出一个内存池，视频源表面将从这里被分配。例如内存池可以位于图形卡上的本地视频内存中，在特殊标记的系统内存中(例如，加速的图形端口(AGP)内存)，一般的系统内存中等等。D3D和DirectDraw文件也提供一个可用内存池位置的描述。

OutputFrameFormat区域指出一个输出帧的Direct3D表面格式。ProcAmp设备可以以匹配输入表面格式的表面格式来输出帧。这个区域确保视频再现器视频再现器410将能够提供到ProcAmp控制硬件的输出帧表面的正确格式。注意到如果在VideoProcessingCaps区域中返回DXVA_VideoProcess_YUV2RGB标记(下面可以看到)，视频再现器视频再现器410可以假定可用的输出格式和一个RGB格式例如RGB32通过这个区域被指定。RGB32是一种RGB格式，它具有用于每一个Red，Green和Blue通道的8位的精确度和8位没有使用的数据。

ProcAmpControlProp区域识别硬件能够执行的ProcAmp操作。图形设备驱动器422返回它支持的ProcAmp操作的组合逻辑。

●DXVA_ProcAmp_None。硬件不支持ProcAmp控制操作。

●DXVA_ProcAmp_Brightness。ProcAmp控制硬件可以执行视频图像的明亮度调节。

●DXVA_ProcAmp_Contrast。ProcAmp控制硬件可以执行视频图像的对比度调节。

●DXVA_ProcAmp_Hue。ProcAmp控制硬件可以执行视频图像的饱和度调节。

●DXVA_ProcAmp_Saturation。ProcAmp控制硬件可以执行视频图像的色调调节。

VideoProcessingCaps区域识别其他可以与一个请求的ProcAmp调节同步执行的操作。下面的标记识别可能的操作：

DXVA_VideoProcess_YUV2RGB。ProcAmp控制硬件可以从YUV颜色空间到RGB颜色空间的转换视频。使用的RGB格式对于每一个颜色成分可以有8位或者更高的精确度。如果这是可能的，可以避免视频再现器视频再现器410内部的一个缓存复制。注意到关于这个标记，没有从RGB颜色空间转换到YUV颜色空间的需要。

DXVA_VideoProcess_StretchX。如果ProcAmp控制硬件能够水平地拉宽或压缩，在视频在进行ProcAmp调节的同时可以执行屏幕高宽比校正。

DXVA_VideoProcess_StretchY。有时屏幕高宽比调节与一个通用图片重定制操作组合来按比例地将视频图像固定到一个应用程序定义的构图空间内。这是一个有点少见的特性。执行用于重新定制视频来适合应用程序窗口的缩放可以和用于ProcAmp调节的缩放同时进行。同时执行这些缩放避免了累积的假象。

DXVA_VideoProcess_SubRects。这个标记指出硬件能够在图像一个矩形(子)区域和整个图像上操作。矩形区域可以通过在DXVA_ProcAmpControlBlt数据结构中的一个源矩形来识别。

DXVA_VideoProcess_AlphaBlend。Alpha混合可以控制其它的图形信息怎样被显示，例如通过设置透明度和/或不透明度的级别。因而，一个alpha数值可以指出一个颜色的透明度或这个颜色与任何背景颜色的混合程度。这样的alpha数值可以从一个完全透明的颜色到一个完全不透明的颜色。

在操作中，alpha混合可以使用一个源和背景颜色数据的像素到像素的混合来完成。一个给出的源颜色的三个颜色成分(红，绿和蓝)的每一个都可以与背景颜色的相应部分混合来执行一个alpha混合操作。在一个典型实施例中，颜色可以一般由一个32位的值显示，每8位用于alpha、红、绿和蓝。

而且使用这个特性可以避免视频再现器视频再现器410的缓存复制。但是，这也是一个很少使用的特性，因为应用程序很少改变与它们的视频流相关的常数alpha数值。

在流程图600的方框608中，视频再现器视频再现器410从在方框604中接收的那些之中选择一个ProcAmp控制属性。在方框610中，视频再现器视频再现器410从图形设备驱动器422请求用于选择的ProcAmp控制属性的一个或者多个数值。在方框624中，对于请求的ProcAmp控制属性，图形设备驱动器422向视频再现器视频再现器410发送数值。这样的数值可能关于一个默认数值、一个增量数值、一个最小数值、一个最大数值等等之中的一个或者多个。

在方框612中，视频再现器视频再现器410从图形设备驱动器422接收被通知用于选择的ProcAmp控制属性的一个或者多个数值。正如从方框612到方框608的流程箭头所指出的，对于多于一个包括所有的可用的ProcAmp控制属性，方框608、610、612和624的操作可以重复。可选地，在一个具有两个或更多的传递的简单通信中，视频再现器视频再现器410可以询问图形设备驱动器关于多于一个也包括所有的可用的ProcAmp控制属性。

一个用于实现方框608、610、612和624的至少部分操作的典型的通用API依下列各项提供：

ProcAmpControlQueryRange

对于每一个ProcAmp属性(明亮度、对比度、饱和度、色调)，视频再现器视频再现器410向图形设备驱动器422询问来确定最小值、最大值、步骤大小(增量)、默认值等等。如果硬件不支持一个特别的ProcAmp控制属性，图形设备驱动器可能响应ProcAmpControlQueryRange功能而返回“E_NOTIMPL”

虽然对于不同的ProcAmp控制属性，图形设备驱动器422可以返回任何数值，但是作为例子提供下面的设置数值(所有列表中的数值都是浮点数值)：

属性      最小值    最大值    默认    增量

明亮度    -100.0F   100.0F    0.0F    0.1F

对比度    0.0F      10.0F     1.0F    0.01F

饱和度    0.0F      10.0F     1.0F    0.01F

色调      -180.0F   180.0F    0.0F    0.1F

如果默认值导致一个视频流的空转换，视频再现器视频再现器410被允许绕过在它的视频流程图上的ProcAmp调节阶段如果策划程序没有改变任何ProcAmp控制属性。

HRESULT

ProcAmpControlQueryRange(

[in]DWORD VideoProperty，

[in]DXVA_VideoDesc*lpVideoDescription，

[out]DXVA_VideoPropertyRange*lpPropRange

)；

VideoProperty识别图形设备驱动器422已经被请求返回信息用于的ProcAmp控制属性。在描述的实施例中，这个区域可能的参数数值是：

DXVA_ProcAmp_Brightness；

DXVA_ProcAmp_Contrast；

DXVA_ProcAmp_Hue；

DXVA_ProcAmp_Saturation。

lpVideoDescription向图形设备驱动器422提供一个ProcAmp调节将要被应用的视频的描述。对于特别的视频流描述类型，图形设备驱动器422可以调节它的ProcAmp特性支持。

lpPropRange识别由VideoProperty参数/区域指定的ProcAmp控制属性的范围(最小值和最大值)，步骤大小和默认值。

typedef struct_DXVA_VideoPropertyRange{

FLOAT MinValue；

FLOAT MaxValue；

FLOAT DefaultValue；

FLOAT Stepsize；

}DXVA_VideoPropertyRange，*LPDXVA_VideoPropertyRange；

在流程图600的方框614中，视频再现器视频再现器410向图形设备驱动器发送一个打开ProcAmp流对象命令。作为响应，图形设备驱动器422打开了在方框626中的ProcAmp流对象。在方框616中，视频再现器视频再现器410命令图形设备驱动器422执行一个ProcAmp调节操作，作为响应，图形设备驱动器422在方框628执行了请求的ProcAmp调节操作。

正如被方框616的弯曲流程箭头所指出的，在需要的时候(例如，无论何时被一个显示视频流的策划程序要求)视频再现器视频再现器410可以继续向图形设备驱动器422发送执行ProcAmp调节操作指令。在方框618中，视频再现器视频再现器410命令图形设备驱动器422结束ProcAmp流对象。

一个用于实现方框614、616、618、626、628和630的至少部分操作的典型的通用API依下列各项提供：

ProcAmpStream Object

在视频再现器视频再现器410已经确定了ProcAmp控制硬件的能力后，可以创建一个ProcAmpStream对象。一个ProcAmpStream对象的创建允许图形设备驱动器422保留需要用于执行请求的ProcAmp调节操作的任何硬件资源。

ProcAmpOpenStream

ProcAmpOpenStream方法创建一个ProcAmpStream对象。

HRESULT

ProcAmpOpenStream(

[in]LPDXVA_VideoDesclpVideoDescription，

[out]HDXVA_ProcAmpStream*lphCcStrm

)；

HDXVA_ProcAmpStream输出参数是ProcAmpStream对象的一个处理，用来识别在将来的通话中被发送的流。

ProcAmpBlt

ProcAmpBlt方法通过在一个比特段的传输操作中将输出写到目标表面来执行ProcAmp调节操作。

HRESULT

ProcAmpBlt(

[in]HDXVA_ProcAmpStream hCcStrm

[in]LPDDSURFACEElpDDSDstSurface，

[in]LPDDSURFACEElpDDSSrcSurface，

[in]DXVA_ProcAmpBlt*ccBlt

)；

源和目标矩形被用于子矩形ProcAmp调节或者拉宽。对于拉宽的支持是可选的(通过Caps标记被报告)。同样地，对于子矩形的支持也不是强制的。

目标表面可以是一个关闭屏幕的无格式、一个D3D渲染目标、一个D3D纹理、一个也是渲染目标的D3D纹理等等。例如，目的表面可以被分配在本地视频内存中。目标表面的像素格式是在DXVA_ProcAmpCaps结构中指出的，除非一个YUV到RGB的颜色空间转化正在与ProcAmp调节操作一起执行。在这种情况下，目标表面格式是一个RGB格式，对于每一个颜色成分有8位或者更高的精确度。

ProcAmpCloseStream

ProcAmpCloseStream方法结束ProcAmpStream对象，命令图形设备驱动器422释放任何与识别的流有关的硬件资源。

HRESULT

ProcAmpCloseStream(

HDXVA_ProcAmpStreamhCcStrm

)；

典型的特殊API实施例

在这一段下面描述的特殊情况和典型API特别适合现有的用于个人电脑的Microsoft Windows操作系统的子集。但是，仍然应该理解为下面显示的原理和伪代码的某个方面可以结合其它的操作系统和/或环境而利用(不作修改或进行修改)。

一个ProcAmp接口的DDI映射

对于一个现有的Microsoft Windows操作系统的子集的DDI下部结构的兼容性，在前一段上面描述的API可以被“映射”到现有的DDI，用于DirectDraw和DirectX。这一段描述了一个映射到现有的DirectDraw和DX-VA DDI的ProcAmp接口。

DX-VA DDI自己分为两个功能组：“DX-VA容器”和“DX-VA设备”。DX-VA容器DDI组的目的是确定显示硬件包括的不同的DX-VA设备的数量和能力。因此，一个DX-VA驱动器只能有一个单一的容器，但是它可以支持多个DX-VA设备。

将ProcAmpQueryCaps通话映射到在DX-VA容器组中的任何DDI进入点是不可行的，因为不像其余的DX-VA，容器方法使用打字参数。但是，DX-VA设备DDI组不使用打字参数，因此将ProcAmp控制接口映射到设备组中的方法是可行的。这一段描述一个ProcAmp接口怎样被映射到DX-VA设备DDI的特殊例子。

De-interlace Container Device

DX-VA设备方法不使用打字参数，因此这些方法可以对于许多不同的目的重复使用。但是，DX-VA设备方法只能在一个DX-VA设备的范围内使用，因此首要的任务是定义和创建一个特殊的“容器设备”。

U.S.Non-provisional Application for Letters Patent Serial No.10/273,505，它被标题为“Methods And Apparatuses For Facilitating Processing Of Interlaced VideoImages For Progressive Video Displays”，它通过上面的参考文献进行合并，包括一个去隔行容器设备的描述。那个应用程序的描述的去隔行容器设备在这里被重复使用用于ProcAmpQueryCaps功能。

DX-VA去隔行容器设备只是一个软件结构，因此它不代表任何在一个物理设备上包含的功能硬件。下面的ProcAmp控制样品(设备)驱动器的伪代码指出容器设备可以怎样被一个驱动器实现。

从一个用户模式部件调用DDI

从一个用户模式部件例如一个(视频)再现器使用DDI的一个8个任务的典型顺序是下面这样的：

1.调用GetMoCompGuids来得到驱动器支持的DX-VA设备列表。

2.如果“去隔行容器设备”GUID是目前存在的，调用CreateMoComp来创建一个DX-VA设备的实例。这个容器设备GUID被定义成下面这样：

DEFINE_GUID(DXVA_DeinterlaceContainerDevice，

0x0e5cb93，0x3046，0x4ff0，0xae，0xcc，0xd5，0x8c，0xb5，0xf0，0x35，0xfc)；

3.调用具用一个dwFunction参数的RenderMocomp，该参数识别一个ProAmpControlQueryModeCaps操作。再一次，lpInputData参数被用来传递输入参数到驱动器，驱动器通过lpOutputData参数来返回它的输出。

4.对于每一个硬件支持的ProcAmp调节特性，再现器调用具用一个dwFunction参数的RenderMocomp，该参数识别一个ProAmpControlQueryModeCaps操作。lpInputData参数被用来传递输入参数到驱动器，驱动器通过lpOutputData参数来返回它的输出。

5.在再现器已经确定了硬件的ProcAmp调节能力后，它调用CreateMocomp来创建一个ProcAmp控制设备的实例。ProcAmp控制设别GUID被定义为下面这样：

DEFINE_GUID(DXVA_ProcAmpControlDevice，

0x9f200913，0x2ffd，0x4056，0x9f，0x1e，0xel，0xb5，0x08，0xf2，0x2d，0xcf)；

6.再现器然后调用用于每一个ProcAmp调节操作的ProcAmp控制设备的具有DXVA_ProcAmpControlBltFnCodede功能参数的RenderMocomp。

7.当再现器不再需要执行任何更多的ProcAmp操作时，它调用DestroyMocomp。

8.驱动器释放ProcAmp控制设备使用的任何资源。

ProcAmpControlQueryCaps

这个方法直接映射一个调用到去隔行容器设备的RenderMoComp方法。DD_RENDERMOCOMPDATA结构像下面一样完成：

●dwNumBuffers为0

●lpBufferInfo为NULL

●dwFunction被定义为DXVA_ProcAmpControlQueryCapsFnCode

●lpInputData指向一个DXVA_VideoDesc结构

●lpOutputData指向一个DXVA_ProcAmpCaps结构

注意到DX-VA容器设备的RenderMoComp方法可以被直接调用，而不用先调用BeginMoCompFrame或者EndMoCompFrame。

ProcAmpControlQueryRange

这个方法直接映射一个调用到去隔行容器设备的RenderMoComp方法。DD_RENDERMOCOMPDATA结构像下面一样完成：

●dwNumBuffers为0

●lpBufferInfo为NULL

●dwFunction被定义为DXVA_ProcAmpControlQueryCapsFnCode

●lpInputData指向一个DXVA_ProcAmpControlQueryRange结构

typedef struct_DXVA_ProcAmpQueryRange{

DWORD           Size；

DWORD           VideoProperty；

DXVA_VideoDesc  VideoDesc；

}DXVA_ProcAmpControlQueryRange，

*LPDXVA_ProcAmpControlQueryRange；

●lpOutputData将指向一个DXVA_VideoPropertyRange结构

注意到DX-VA容器设备的RenderMoComp方法可以被直接调用，而不用先调用BeginMoCompFrame或者EndMoCompFrame。

ProcAmpControlOpenStream

这个方法直接映射到DD_MOTIONCOMPCALLBACKS结构的一个CreateMoComp方法，这里GUID为ProcAmp设备GUID，pUncompData指向一个包含非数据(全零)的结构，pData指向一个DXVA_VideoDesc结构。

如果一个驱动器支持压缩视频的加速解码，再现器可以调用驱动器来创建两个DX-VA设备——一个来执行由DirectX VA视频解码规范定义的实际视频解码工作，另一个被严格使用在ProcAmp调节中。

**例子：映射CreateMoComp到ProcAmpControlOpenStream**

下面的典型伪代码表示一个驱动器可以怎样映射CreateMoComp DDI调用到ProcAmpControlOpenStream的调用。伪代码表示CreateMoComp功能怎样被用于ProcAmp。如果一个驱动器支持其它的DX-VA功能例如解码MPEG-2视频流，下面举例的代码可以被扩展到包括额外的DX-VA GUID的处理。

DWORD APIENTRY

CreateMoComp(

LPDDHAL_CREATEMOCOMPDATAlpData

)

{

//确定它是一个我们希望的guid。

If(！ValidDXVAGuid(lpData-＞lpGuid)){

DbgLog((LOG_ERROR，1，

TEXT(“No formats supported for this GUID”)))

LpData-＞ddRVal＝E_INVALIDARG；

Return DDHAL_DRIVER_HANDLED；

}

//寻找去隔行容器设备GUID。

if(*lpData-＞lpGuid＝DXVA_DeinterlaceContainerDevice){

DXVA_DeinterlaceContainerDeviceClass*lpDev＝

NewDXVA_DeinterlaceContainerDeviceClass(

*lpData-＞lpGuid，

DXVA_DeviceContainer)；

If(lpDev){

LpData-＞ddRVal＝DD_OK；

}

else{

lpData-＞ddRVal＝E_OUTOFMEMORY；

}

lpData-＞lpMoComp-＞lpDriverReservedl＝

(LPVOID)(DXVA_DeviceBaseClass*)lpDev；

return DDHAL_DRIVER_HANDLED；

}

//寻找ProcAmp控制设备GUID

if(*lpData-＞lpGuid＝DXVA_ProcAmpControlDevice){

DXVA_ProcAmpControlDeviceClass*lpDev＝

New DXVA_ProcAmpControlDeviceClass(

*lpData-＞lpGuid，

DXVA_DeviceProcAmpControl)；

If(lpDev){

LPDXVA_VideoDesc lp VideoDescription＝

(LPDXVA_VideoDesc)lpData-＞lpData；

lpData-＞ddRVal＝

lpDev-＞ProcAmpControlOpenStream(

lpVideoDescription)；

if(lpData-＞ddRVal！＝DD_OK){

delete lpDev；

lpDev＝NULL；

}

}

else{

lpData-＞ddRVal＝E_OUTOFMEMORY；

}

lpData-＞lpMoComp-＞lpDriverReserverdl＝

(LPVOID)(DXVA_DeviceBaseClass*)lpDev；

return DDHAL_DRIVER_HANDLED；

}

lpData-＞ddRVal＝DDERR_CURRENTLYNOTAVAIL；

return DDHAL_DRIVER_HANDLED；

}

**例子：实现GetMoCompGuid**

除了CreateMoComp DDI功能之外，一个驱动器也能够实现DD_MOTIONCOMPCALLBACKS结构的GetMoCompGuids方法。下面的典型的伪代码表示在一个驱动器中实现这个功能的一个方法。

//这是一个驱动器支持的DV-VA设备GUID的列表，这个列表包括解码器，//ProcAmp和去隔行容器设备。列表中的GUID的顺序没有意义。

DWORD g_dwDXVANumSupportedGUIDs＝2；

Const GUID*g_dwDXVASupportedGUIDs[2]＝{

&DXVA_DeinterlaceContainerDevice，

&DXVA_ProcAmpControlDevice

}；

DWORD APIENTRY

GetMoCompGuids(

PDD_GETMOCOMPGUIDSDATA lpData

)

{

DWORD dwNumToCopy；

//检查来看这是否是一个GUID请求或者一个计数要求

if(lpData-＞lpGuids){

dwNumToCopy＝

min(g_dwDXVANumSupportedGUIDs，

lpData-＞dwNumGuids)；

for(DWORDi＝0；i＜dwNumToCopy；i++){

lpData-＞lpGuids[i]＝

*g_DXVASupportdGUIDs[i]；

}

}

else{

dwNumToCopy＝g_dwDXVANumSupportedGUIDs；

}

lpData-＞dwNumGuids＝dwNumToCopy；

lpData-＞ddRVal＝DD_OK；

return DDHAL_DRIVER_HANDLED；

}

ProcAmpControlBlt

这个方法直接映射到DD_MOTIONCOMPCALLBACKS结构的一个CreateMoComp方法，这里：

●dwNumBuffers为2

●lpBufferInfo指向一个两个表面的排列。这个排列的第一个元素是目标表面，这个元素的第二部分是源表面。

●dwFunction被定义为DXVA_ProcAmpControlBltFnCode

●lpInputData指向下面结构：

typedef struct_DXVA_ProcAmpControlBlt{

DWORD    Size；

RECT     DstRect；

RECT     SreRect；

FLOAT    Alpha；

FLOAT    Brightness；

FLOAT    Contrast；

FLOAT    Hue；

FLOAT    Saturation；

}DXVA_ProcAmpControlBlt；

●lpOutputData为空。

注意到用于DX-VA容器设备的ProcAmp、RenderMoComp方法可以被直接调用，而不用先调用BeginMoCompFrame或者EndMoCompFrame。

**例子：映射RenderMoComp到ProcAmpControlBlt**

下面的典型的伪代码表示一个驱动器可以怎样映射CreateMoComp DDI的调用到ProcAmpBlt的调用。这个举例的代码表示CreateMoComp功能怎样被用于ProcAmp调节。如果一个驱动器支持其它的DX-VA功能例如解码MPEG-2视频流，下面举例的代码可以被扩展到包括额外的DX-VAGUID的处理。

DWORD APIENTRY

RenderMoComp(

LPDDHAL_RENDERMOCOMPDATA lpData

)

{

if(lpData-＞dwFunction＝DXVA_ProcAmpControlBltFnCode)

{

DXVA_ProcAmpControlDeviceClass*pDXVADev＝

(DXVA_ProcAmpControlDeviceClass*)pDXVABase；

DXVA_PrcoAmpControlBlt*lpBlt＝

(DXVA_ProcAmpControlBlt*)lpData-＞lpInputData；

LPDDMCBUFFERINFO lpBuffInfo＝lpData-＞lpBufferInfo；

lpData-＞ddRVal＝pDXVADev-＞ProcAmpControlBlt(

lpBuffInfo[0].lpCompSurface，

lpBuffInfo[1].lpCompSurface，

lpBlt)；

return DDHAL_DRIVER_HANDLED；

}

lpData-＞ddRVal＝E_INVALIDARG；

return DDHAL_DRIVER_HANDLED；

}

ProcAmpControlCloseStream

这个方法直接映射到DD_MOTIONCOMPCALLBACKS的一个CreateMoComp方法。

**例子：映射DestroyMoComp到ProcAmpControlCloseStream**

下面的典型的伪代码表示一个驱动器可以怎样映射CreateMoComp DDI调用到ProcAmpControlCloseStream的调用。这个举例的代码表示CreateMoComp功能怎样被用于ProcAmp控制。如果一个驱动器支持其它的DX-VA功能例如解码MPEG-2视频流，下面举例的代码可以被扩展到包括额外的DX-VA GUID的处理。

DWORD APIENTRY

DestroyMoComp(

LPDDHAL_DESTROYMOCOMPDATAlpData

)

{

DXVA_DeviceBaseClass*pDXVABase＝

(DXVA_DeviceBaseClass*)

lpData-＞lpMoComp-＞lpDrvierReservedl；

if(pDXVABase＝NULL){

lpData-＞ddRVal＝E_POINTER；

return DDHAL_DRIVER_HANDLED；

}

switch(pDXVABase-＞m_DeviceType){

case DXVA_DeviceContainer；

lpData-＞ddRVal＝S_OK；

delete pDXVABase；

break；

case DXVA_DeviceProcAmpControl：

{

DXVA_ProcAmpControlDeviceClass*pDXVADev＝

(DXVA_ProcAmpControlDeviceClass*)pDXVABase；

lpData-＞ddRVal＝pDXVADev-

＞ProcAmpControlCloseStream()；

delete pDXVADev；

}

break；

}

return DDHAL_DRIVER_HANDLED；

}

用于计算机或者其它电子设备的典型操作环境

图7举例说明一个典型计算(或者一般的电子设备)操作环境700，它能够在至少一个系统、设备、成分、装置、协议、途径、方法、处理、一些其中的组合等等中实现来简化这里描述的视频再现器与图形设备驱动器之间的交互作用。可以在下面描述的计算机和网络环境或者在一个单机环境中利用计算环境700。

典型的电子设备操作环境700只是一个环境的例子，并不意味着对使用的范围或可适用的电子结构(包括计算机、游戏控制台、电视等等)的功能提出任何限制。电子设备环境700也不应该被解释为具有任何关于图7中描述的部件的任何一个或者任何组合的依赖和需要。

额外地，简化视频再现器与图形设备驱动器之间的交互作用可以通过许多其它的一般目的或者特殊目的的电子设备(包括计算机系统)环境或者配置来实现。适合使用的已知的电子(设备)系统、环境和/或配置包括个人计算机、服务器计算机、瘦客户端、胖客户端等等，但是并不仅限于此。

系统总线708表示几种有线或者无线总线结构中的一个或者多个，包括一个内存总线或者内存控制器，一个外设总线，一个加速的图形端口和一个处理器或者使用任何一种总线结构的本地总线。作为例子，这样的结构可以包括一个工业标准结构(ISA)总线，一个微通道结构(MCA)总线，一个增强ISA(EISA)总线，一个视频电子标准电子标准协会(VESA)本地总线，一个周边元件扩展接口(PCI)总线也被叫做夹层总线，一些它们的组合等等。

计算机702典型地包括一种电子可访问媒体。这种媒体可以是任何可被计算机或者其它电子设备访问的可用媒体，它包括易失性和非易失性媒体，可移动和固定媒体和存储和传递媒体。

系统内存706在易失性内存的形态下包括电子可访问媒体，例如随机访问存储器(RAM)710，和/或非易失性内存，例如只读存储器(ROM)。例如在启动期间，一个基本输入/输出系统(BIOS)714被典型地存储在ROM702中，包含有助于在计算机702内的元件中传递信息的基本程序。RAM 710典型地包括可以被立即访问的和/或目前正在被处理单元704操作的数据和/或程序模块/指令。

计算机702也可以包括其它的可移动/固定和/或易失性/非易失性存储媒体。作为例子，图7举例说明了一个用于从一个(典型的)固定的非易失性的磁盘媒体(没有分别表示)读取或者写入的硬盘驱动器或者盘片驱动器阵列716；一个用于从一个(典型的)可移动的非易失性的磁盘媒体720(例如软盘)读取或者写入的磁盘驱动器718；一个可选的用于从一个(典型的)可移动的非易失性的光盘724例如一个CD-ROM、DVD或者其它的光媒体读取和/或者写入的光盘驱动器722。硬盘驱动器716，磁盘驱动器718和光盘驱动器722分别通过一个或者多个存储媒体接口726连接到系统总线708。可选地，硬盘驱动器716，磁盘驱动器718和光盘驱动器722可以通过一个或者多个分开的或者组合的接口(没有表示)连接到系统总线708。

磁盘驱动器和它们的相关电子可访问媒体提供一个电子可执行的固定存储器，例如用于计算机702的数据结构，程序模块和其它数据。虽然典型的计算机702举例说明了硬盘716、可移动磁盘720、可移动光盘724，但是应该意识到电子可访问媒体的其它类型也能存储可以被电子设备访问的指令，例如磁带或者其它的磁存储设备、闪存、CD-ROM、数字化视频光盘(DVD)或者其它光存储、RAM、ROM、电子可擦可编程只读存储器(EEPROM)等等。这样的媒体也可以包括所谓的特殊目的或者硬件集成电路(IC)芯片。换句话说，可以利用任何电子可访问媒体来实现典型的电子系统和环境700的存储媒体。

任何数量的编程模块(或者其它单元或者指令集)可以被存储在硬盘716、磁盘720、光盘724、ROM 712和/或RAM 710，包括作为通用的例子：一个操作系统728，一个或者多个应用程序730，其它的程序模块732和程序数据734。作为特殊的例子但不仅限于此，视频再现器视频再现器410、图形接口412和设备驱动器414(图4中的所有)可以是操作系统728的一部分。图形设备驱动器422可以是程序模块732的一部分，可选地与操作系统728具有紧密联接和/或整体的关系。而且，一个策划程序例如Wmdows Media 9是一个应用程序730的例子。目前在系统内存中的图像控制和/或图形数据可以是程序数据734的一部分。

例如，一个改变ProcAmp或者其它视频设置的用户可以通过输入设备例如一个键盘736和一个指示设备738(例如一个鼠标)来输入命令和/或信息到计算机702。其它的输入设备740(没有特别的表示)可以包括一个麦克风、操纵杆、游戏垫、圆盘式卫星电视天线、串口、扫描仪和/或其它类似设备。这些和其它的输入设备通过与系统总线708耦合的输入/输出接口742连接到处理单元704。但是，它们和/或输出设备可以代替地被其它接口和总线结构连接，例如并口、游戏端口、通用串行总线(USB)端口、一个IEEE 1394(“火线”)接口，一个IEEE802.11无线接口，一个Bluetooth无线接口等等。

一个监视/观看屏幕744(图4的显示设备436的一个例子)或者其它类型的显示设备也可以通过一个接口连接到系统总线708，例如一个视频适配器746。视频适配器746(或者其它元件)可以是或者可以包括一个用于处理密集图形的计算和处理要求显示需要的一个图形卡(图形设备424的一个例子)。典型地，一个图形卡包括一个GPU(例如GPU 426)、视频RAM(VRAM)(视频内存432的例子)等等来优化图形操作的迅速性能。除了监视器744之外，其它的输出外围设备可以包括例如扬声器(没有表示)和打印机748等元件，它们可以通过输入/输出接口742连接到计算机702。

计算机702可以在一个使用逻辑连接到一个或者多个远程计算机的网络化的环境中操作，例如一个远程计算机设备750。作为例子，远程计算机设备750可以是一个个人计算机、一个便携式计算机(例如，膝上型电脑，tablet电脑、PDA，流动式电台等等)，掌上型或者超小型电脑，一个游戏设备，一个服务器，一个路由器，一个网络计算机，一个对等设备，其它普通的网络节点，或者像上面列出的另一种计算机类型等等。可是，远程计算机设备750被举例描述为是一个便携式计算机，它可以包括本文描述的关于计算机702的元件和特性中的许多或者全部。

在计算机702和远程计算机750之间的逻辑连接被描述为一个局域网(LAN)752和一个通用的广域网(WAN)754。这种网络环境普遍用在在办公室、企业级计算机网络、企业内部互联网、固定和移动电话网、其它无线网络、游戏网络、其中的一些组合等等之中。

当在一个LAN网络环境中实现时，计算机702通常通过一个网络接口或者适配器756连接到LAN 752。当在一个WAN网络环境中实现时，计算机702典型地包括一个调制解调器758或者其它用于在WAN 754上建立通信的装置。调制解调器758对于计算机702可以是内置的或者外置的，它可以通过输入/输出接口742或者任何其它的适当机制来连接到系统总线708。应该意识到，描述的网络连接是典型的，可以在计算机702和750之间使用其它建立通信连接的装置。

在一个网络环境中，例如电子设备环境700所描述的，描述的与计算机702相关的程序模块或者其它指令可以被完全地或者部分地存储在一个远程内存存储设备中。作为例子，远程应用程序760驻留在远程计算机750的一个内存元件中，但是可以通过计算机702被使用或者另外被访问。并且出于说明的目的，应用程序730和其它电子可执行指令例如操作系统728在本文中被描述为分离的方框，但是这种在不同时间驻留在计算机设备702(和/或远程计算机750)的不同存储元件中的程序、元件和其它指令，和被计算机702(和/或远程计算机750)的数据处理器704所执行的程序、元件和其它指令是已知的。

虽然系统、媒体、方法、协议、途径、处理、装置和其它的实施例已经由具体到结构的语言、逻辑、算法、功能特性和/或图表中作了描述，但是应该知道在随后权利要求中定义的发明没有必要限制到描述的特定特性或者图表中。进而，特殊的特性和图表被公开为实现权利要求中的发明的典型形态。

Claims (11)

1.一种用于简化一个或者多个视频再现器与至少一个图形设备驱动器之间的交互的方法，这个方法包括步骤：

将一查询从视频再现器传送到图形设备驱动器，其中所述查询：

被指向所述图形设备驱动器能够提供给所述视频再现器的图像处理操作；并且

包括要显示的视频的描述；以及

在所述视频再现器接收来自所述图形设备驱动器的响应，所述响应指示了所述图形设备驱动器能够提供给所述视频再现器的至少一个图像处理操作。

2.如权利要求1所述的方法，其特征在于，所述图形设备驱动器能够通过相关的图形硬件向所述视频再现器提供所述至少一个图像处理操作。

3.如权利要求1所述的方法，其特征在于，所述视频再现器将另一查询传送到所述图形设备驱动器，所述另一查询请求所述至少一个图像处理操作，其相关参数为：

最小值；

最大值；

增量步骤大小值；以及

默认值。

4.如权利要求1所述的方法，其特征在于，所述视频再现器向所述图形设备驱动器进一步查询该图形设备驱动器所支持的设备的列表。

5.如权利要求1所述的方法，其特征在于，进一步包括在所述图形设备驱动器处基于所述要显示的视频的描述修改所述图像处理操作。

6.如权利要求5所述的方法，其特征在于，所述修改步骤对所述图像处理操作进行调节以支持与所述要显示的视频的描述相关联的特殊类型的视频流。

7.如权利要求1所述的方法，其特征在于，进一步包括：

从所述视频再现器向所述图形设备驱动器传送另一查询，所述另一查询被指向所述图形设备驱动器能够提供给所述视频再现器的所述至少一个图像处理操作的属性能力；以及

在所述视频再现器接收来自所述图形设备驱动器的另一响应，所述另一响应指示了所述图形设备驱动器能够提供给所述视频再现器的所述至少一个图像处理操作的至少一个属性能力。

8.如权利要求1所述的方法，其特征在于，进一步包括：

从所述视频再现器向所述图形设备驱动器传送另一查询，所述另一查询被指向所述图形设备驱动器能够提供给所述视频再现器的所述至少一个图像处理操作相关的同时视频处理操作能力；以及

在所述视频再现器接收来自所述图形设备驱动器的另一响应，所述另一响应指示了所述图形设备驱动器能够提供给所述视频再现器的所述至少一个图像处理操作相关的至少一个同时视频处理操作能力。

9.如权利要求1所述的方法，其特征在于，进一步包括：

从所述视频再现器向所述图形设备驱动器传送另一查询，所述另一查询被指向所述图形设备驱动器能够提供给所述视频再现器的所述至少一个图像处理操作的属性值；以及

在所述视频再现器接收来自所述图形设备驱动器的另一响应，所述另一响应指示了所述图形设备驱动器能够提供给所述视频再现器的所述至少一个图像处理操作的至少一个属性值。

10.一种被配置为与一个使用一个协议的视频再现器通信的图形设备驱动器，其中的协议包括一个或多个从图形设备驱动器传送到视频再现器的格式，所述一个或多个格式包括用ProcAmp控制特性填充的至少一个字段，所述ProcAmp控制特性通过图形设备驱动器对于视频再现器可用的，以及用视频处理操作填充的至少一个字段，图形设备驱动器可以导致这个视频处理操作与一个ProcAmp调节操作同时执行。

11.一种被配置为与一个使用一个协议的图形设备驱动器通信的视频再现器，其中的协议包括一个或多个从视频再现器传送到图形设备驱动器的格式，所述一个或多个格式包括用视频描述填充的至少一个字段，视频再现器将和一个策划应用程序一起显示这个视频描述，以及用选择的ProcAmp控制特性填充的至少一个字段，所述选择的ProcAmp控制特性指出一个到图形设备驱动器的关于操作选择的ProcAmp控制特性的值的请求。

Images