摘要：分析了多媒体设备驱动程序的体系结构及视频采集与解压卡的驱动程序设计方案。描述了核心态驱动程序的处理流程，提供了用户态驱动程序的设计思路和具体算法。

    关键词：驱动程序 IRP（输入输出请求包） 驱动程序对象 设备对象

Windows NT的结构决定了应用程序不能直接操作硬件设备，它只能通过一个中间层来读写和控制设备，这个中间层就是驱动程序。驱动程序位于计算机软件的最低层（HAL 为硬件抽象层），直接与硬件设备的特性联系在一起。编写驱动程序不仅要了解设备的特性，而且还要了解操作系统的结构，难度较大。本文比较详细地分析了视频采集与解压卡的驱动程序设计思路。

1 视频采集与解压卡驱动程序的结构

多媒体设备相对变通设备来说，有两个特点：数据流量大；对最终期限要求高（即实时性要求比较高）。对于视频采集与解压卡这类多媒体设备来说，驱动程序的编写有其特定的方式。多媒体驱动程序的结构如图1所示。一般说来，根据其代码运行的特权级可分为两层：核心态的驱动程序和用户态的驱动程序。核心态的驱动程序运行于内核模式。可以执行特权级指令，对任何I/O设备有全部的访问权，还能够访问任何虚地址和控制虚拟内存硬件。

用户模式的驱动程序实质上是一个动态链接库（DLL）。它运行在用户态，应用程序向这个接口发出消息请求一定的操作。它们调用WIN32函数与内核模式的驱动程序通讯（WIN32函数又调用NT执行体提供的函数，这些执行体函数提供从用户态到核心态的上下文转换）。用户模式的驱动程序根据接收的消息采取适当的操作，完成操作后将结果返回给应用程序。但是这种结构只适用于解压一幅幅的位图，并不适合采集和解压本设备产生的视频流。

此卡既要采集又要解压，若用标准模式进行设计，就要同时编写视频采集和视频解压的驱动程序，其中还要对解压程序进行改造，编写复杂，尤其调试会很困难。在这种情况下，使用本设计方案，既可满足要求，又可减小设计难度。

内核模式的驱动程序与一般驱动程序无多大的区别，只负责读取数据和进行设备控制。用户模式的驱动程序要处理大部分的事务。在解压时，驱动程序要向设备写入待解压的数据，从设备中取得解压后的数据，向应用程序提供一帧图像的RGB数据。从设备得到的数据是分场存放的4：2：2的YcrCb格式的数据，驱动程序将每帧数据按行进行格式转换，组合成完整的一帧数据（QCIF）交付给应用程序。

2 内核模式的驱动程序的设计

由于多媒体的数据量很大，按照常规的方法（采用IRP包进行数据传输）设计将面临着一个无法解决的问题——中断太快驱动程序将来不及处理。因此必须采用一种新的方法：在驱动程序中建立两块缓冲区（分别用于读写），应用层驱动程序与核心层驱动程序共用缓冲区。当设备中断发生时，根据发生的中断进行处理。如果是读中断，先把数据从设备中读到缓冲区中，发出一个DPC（推迟过程调用），通知应用层驱动程序该缓冲区数据可用，可以取走数据了。如果是写中断，先把缓冲区中的数据写到设备的FIFO中，然后发出一个DPC，通知用户模式驱动程序该缓冲区数据已失效，需要写入新数据。

驱动程序工作流程如图2所示。内核模式向外显露DriverEntry（驱动程序必须要有的一个全程）接口，其它的全程没有固定的名字，为了让I/O管理器找到这些例程，DriverEntry例程负责建立这些函数指针。I/O管理器从非分页系统内存分配一个IRP，响应一个I/O请求，基于由用户指定的I/O函数，把IRP传送给合适的驱动程序Dispatch例程，

    摘要：分析了多媒体设备驱动程序的体系结构及视频采集与解压卡的驱动程序设计方案。描述了核心态驱动程序的处理流程，提供了用户态驱动程序的设计思路和具体算法。

    关键词：驱动程序 IRP（输入输出请求包） 驱动程序对象 设备对象

Windows NT的结构决定了应用程序不能直接操作硬件设备，它只能通过一个中间层来读写和控制设备，这个中间层就是驱动程序。驱动程序位于计算机软件的最低层（HAL 为硬件抽象层），直接与硬件设备的特性联系在一起。编写驱动程序不仅要了解设备的特性，而且还要了解操作系统的结构，难度较大。本文比较详细地分析了视频采集与解压卡的驱动程序设计思路。

1 视频采集与解压卡驱动程序的结构

多媒体设备相对变通设备来说，有两个特点：数据流量大；对最终期限要求高（即实时性要求比较高）。对于视频采集与解压卡这类多媒体设备来说，驱动程序的编写有其特定的方式。多媒体驱动程序的结构如图1所示。一般说来，根据其代码运行的特权级可分为两层：核心态的驱动程序和用户态的驱动程序。核心态的驱动程序运行于内核模式。可以执行特权级指令，对任何I/O设备有全部的访问权，还能够访问任何虚地址和控制虚拟内存硬件。

用户模式的驱动程序实质上是一个动态链接库（DLL）。它运行在用户态，应用程序向这个接口发出消息请求一定的操作。它们调用WIN32函数与内核模式的驱动程序通讯（WIN32函数又调用NT执行体提供的函数，这些执行体函数提供从用户态到核心态的上下文转换）。用户模式的驱动程序根据接收的消息采取适当的操作，完成操作后将结果返回给应用程序。但是这种结构只适用于解压一幅幅的位图，并不适合采集和解压本设备产生的视频流。

此卡既要采集又要解压，若用标准模式进行设计，就要同时编写视频采集和视频解压的驱动程序，其中还要对解压程序进行改造，编写复杂，尤其调试会很困难。在这种情况下，使用本设计方案，既可满足要求，又可减小设计难度。

内核模式的驱动程序与一般驱动程序无多大的区别，只负责读取数据和进行设备控制。用户模式的驱动程序要处理大部分的事务。在解压时，驱动程序要向设备写入待解压的数据，从设备中取得解压后的数据，向应用程序提供一帧图像的RGB数据。从设备得到的数据是分场存放的4：2：2的YcrCb格式的数据，驱动程序将每帧数据按行进行格式转换，组合成完整的一帧数据（QCIF）交付给应用程序。

2 内核模式的驱动程序的设计

由于多媒体的数据量很大，按照常规的方法（采用IRP包进行数据传输）设计将面临着一个无法解决的问题——中断太快驱动程序将来不及处理。因此必须采用一种新的方法：在驱动程序中建立两块缓冲区（分别用于读写），应用层驱动程序与核心层驱动程序共用缓冲区。当设备中断发生时，根据发生的中断进行处理。如果是读中断，先把数据从设备中读到缓冲区中，发出一个DPC（推迟过程调用），通知应用层驱动程序该缓冲区数据可用，可以取走数据了。如果是写中断，先把缓冲区中的数据写到设备的FIFO中，然后发出一个DPC，通知用户模式驱动程序该缓冲区数据已失效，需要写入新数据。

驱动程序工作流程如图2所示。内核模式向外显露DriverEntry（驱动程序必须要有的一个全程）接口，其它的全程没有固定的名字，为了让I/O管理器找到这些例程，DriverEntry例程负责建立这些函数指针。I/O管理器从非分页系统内存分配一个IRP，响应一个I/O请求，基于由用户指定的I/O函数，把IRP传送给合适的驱动程序Dispatch例程，