NT下视频采集及解压驱动程序的设计与实现

　　Windows NT的结构决定了应用程序不能直接操作硬件设备，它只能通过一个中间层来读写和控制设备，这个中间层就是驱动程序。驱动程序位于计算机软件的最低层(HAL

　　为硬件抽象层)，直接与硬件设备的特性联系在一起。编写驱动程序不仅要了解设备的特性，而且还要了解操作系统的结构，难度较大。本文比较详细地分析了视频采集与解压卡的驱动程序设计思路。　

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

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

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

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

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

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

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