CN100501735C - 透明地处理多媒体数据的系统与方法 - Google Patents

Abstract

一种多媒体数据处理系统与方法，其透明地实时处理视频和/或音频流。根据本发明的一实施例的系统的操作不需要任何来自视频和/或音频流制作者或客户端应用程序的干涉或介入。使用这种透明解决方案，可以无缝地处理视频和/或音频流，且完全独立于用户所选择使用的特殊客户端应用程序。在一实施例中，本发明使用外部服务来监控新进程并向这些进程添加代码。本发明通过热修补(hot-patching)内存中的软件并通过只考虑选择服务调用而插入所述系统中。

Description

透明地处理多媒体数据的系统与方法

本申请案主张于2005年6月8日申请的题为“System and Method for TransparentlyProcessing Multimedia Data”的第60/688,838号临时申请案的优先权，且是于2005年9月29日申请的题为“System and Method for Transparently Processing Multimedia Data，”的第11/241,312号申请案的部分接续申请案，两个申请案因此都全文并入本文中。同一受让人的有关申请案为于2005年7月14日申请的题为“Facial Features-Localized andGlobal Real-Time Video Morphing”的第11/183,179号专利申请案；及于2004年1月28日申请的题为“Use of Multimedia Data for Emoticons In Instant Messaging”的第10/767,132号专利申请案，其因此都全文并入本文中。

技术领域

本发明大体上是关于多媒体数据处理，且明确地说是关于用于智能地且透明地实时处理多媒体流的用户模式多媒体处理层。

背景技术

在过去几年中，人们互相以电子方式建立的联系已经大大增加。人们使用多种通信模式互相以电子方式通信，所述模式例如电子邮件、文本通讯等。尤其是实时视频和音频通信(例如IM聊天，包括视频和/或音频聊天)已变得很普遍。

为了进行视频和音频实时聊天，常把照相机(常称为网络照相机)连接到用户的计算机，并把照相机捕捉到的视频和/或音频数据传输到所述计算机。用户有几个选择：传输静止图像、视频和/或音频数据，如即时通讯(IM)、现场直播的视频流、为了创建电影而进行的视频捕捉、视频监视、因特网监视、因特网网络照相机等。对于这些用途在市场上有多种客户端应用程序。例如，只对即时通讯而言，用户可从几个应用程序选择，所述应用程序包括微软公司(Redmond，WA)的MSN

通讯软件、ICQ公司的ICQ、美国在线公司(Dulles，VA)的美国在线即时通讯软件(AIM)，和雅虎公司(Sunnyvale，CA)的Yahoo！

即时通讯软件。

用户常希望以某些方式改变视频和/或音频流。由于多种原因，可能希望进行这些修改。例如，用户可能想要看上去和/或听上去像另外一个人(例如，像某个名人，某个动画角色等)。另一个例子是当用户只希望不被认出而保持匿名。又一个例子是当用户想要看上去像他自己的更好一面(例如，用户可能没有为业务会议而盛装打扮，但他想要表现得专业)。又一个例子是当用户想要创建视频和/或音频特殊效果时。由于这些原因和各种其他原因，用户常希望修改由他们的网络照相机和/麦克风实际上捕捉到的视频和/或音频流。在一个例子中，用户有一个他们选择的化身。已公布的美国申请案20030043153描述一种用于修改化身的系统。

常规视频和音频处理系统不能自动地且透明地执行这些修改可能需要的适当处理功能。现有的系统在很大程度上是不透明的，需要配置下游应用程序以便利用视频和/或音频修改能力。常见的情况是需要把处理组件并入客户端应用程序中，以便实施这些修改。这些处理组件是专用处理组件。或者，需要使用第三方组件来向系统流抢先添加经处理的输出。又一个选择是在多媒体数据捕捉装置的驱动程序中引入视频和/或音频修改能力。然而，客户端应用程序仍将需要进行选择来施加效果，且将必须定制每个装置的驱动程序以便并入所述功能性。此外，在驱动程序中不可能进行高级处理，因为环境中没有这些高级处理所需的适当服务。另外，驱动程序中的一切事物都是很静止的，且需要大量的测试来保证系统稳定性，从而使得几乎不可能在驱动程序中提供灵活且可扩展的架构。另外，如果处理功能性在驱动程序中，那么除非用户为装置下载新的驱动程序，否则不能实现与现有装置和驱动程序的向后兼容性。

需要一种系统与方法，其可以透明地实时修改静止图像、视频和/或音频流，而独立于所使用的特殊客户端应用程序，且不需要修改装置的驱动程序。

发明内容

本发明是一种透明地实时处理视频和/或音频流的多媒体数据处理系统与方法。根据本发明的一实施例的系统的操作不需要任何来自视频和/或音频流制作者或客户端应用程序的干涉或牵涉。使用这种透明解决方案，可以无缝地处理视频和/或音频流，且完全独立于用户选择使用的特殊客户端应用程序。因此，根据本发明的一些实施例的系统可与用户选择的任何客户端应用程序一起使用。这允许为最终用户的利益创建大量视频和/或音频效果和/或改进。

在一实施例中，由用户模式视频处理层(UMVPL)或用户模式音频处理层(UMAPL)执行对多媒体数据的处理。在一实施例中，UMVPL或UMAPL位于在多媒体源或多媒体槽与客户端应用程序之间的多媒体数据路径上。处理层位于用户模式中，而不是内核模式中。内核是非常有限且敏感的环境，且其没有施加高级效果所需的许多服务，尤其是对于视频而言。另外，在内核中容易使系统崩溃；用户模式环境要安全得多。此外，当在用户模式中时，对于每个程序而言可改变视频和/或音频流。因此，用户可为每个单独进程(应用程序)引入一组不同的效果，或者只选择在一个进程中产生效果而其他进程保持不受影响。最后，对于多媒体流内核模式的入口非常局限性，且因此其可以被拦截。当代码在内核中时，要进行拦截就困难得多。

在一实施例中，根据本发明的一实施例的系统包括进程创建监控器，和注入器服务(Injector Service)以及UMVPL或UMAPL。进程创建监控器监控每个已创建进程，并告知注入器服务。这个注入器服务随后向每个进程注入一注入器钩子库(注入器钩子动态链接库(DLL))。这些钩子又在多媒体数据到达其目的地之前经由UMVPL或UMAPL重新路由每个进程。

在一实施例中，多媒体数据源可为用户的装置(如网络照相机、麦克风等)，且目的地可为客户端应用程序。在另一实施例中，多媒体数据流的方向可从客户端应用程序到用户的装置(例如视频输出装置(例如记录设备)、扬声器等)。

在一实施例中，本发明使用外部服务来监控新进程并向这些进程添加代码。本发明通过热修补内存中的软件并通过只考虑选择服务调用来插入所述系统中。这种解决方案因此是通用的。所述系统可施加一连串效果。

本说明书中描述的特征和优点不包括所有特征和优点，且尤其是，考虑到图示、说明书和权利要求书，所属领域的技术人员将明了许多额外特征和优点。此外，应注意在说明书中使用的语言主要是为易读性和指导性目的而选择的，且不是选择用来描绘或限制本标的物。

附图说明

本发明具有其他优点和特征，根据本发明的以下具体实施方式和随附权利要求书(当结合附图来看时)，所述优点和特征将更为显而易见，

图1是说明连接到主机的视频/音频捕捉装置如何使用客户端应用程序来与另一类似装备在网络上通信的方框图。

图2A说明来自图1的系统的一侧的一实施例。

图2B是说明以上参考图2A描述的系统中的数据流的方框图。

图3A是说明根据本发明的一实施例的系统的方框图。

图3B是说明根据本发明的一实施例的系统中的数据流的方框图。

图4A、4B和4C是描述在根据本发明的一实施例的系统中从打开客户端应用程序开始，然后打开视频流到关闭所述流的特殊例子的流程图。

图5是大体上确定由根据本发明的一实施例的进程创建监控器、注入器服务和UMVPL进行的步骤的流程图。

图6是对注入器钩子部分比图3B更详细地展示一架构实施例的多种组件及其关系的图。

图7是展示根据本发明的一实施例的视频帧的典型数据流的图。

具体实施方式

将详细参考本发明的若干实施例。尽管将主要参考使用标准Windows内核流协议的多媒体装置的Windows环境中的透明视频/音频处理系统的实施，但是所属领域技术人员知道，相同的概念可在包括Linux、Mac OS或其它专有或公开操作系统平台(包括实时操作系统)的各种操作环境中的任一种操作环境中实施。请注意，尽管一些实施例在视频处理的情况下加以论述，但是这些实施例也可应用于任何类型的多媒体处理(例如，音频、静止图像等)。另外，应注意，尽管一些实施例使多媒体源为用户装置且使数据槽(data sink)为客户端应用程序来加以论述，但是可在这些实施例中时使数据流反向。

图1是说明连接到主机的视频/音频捕获装置可如何使用客户端应用程序来经由网络与另一类似装备(setup)通信的方框图。所述常规系统可由用户用于彼此传输多媒体信息。系统100包含数据捕获装置110a和110b、计算机系统120a和120b、网络130和客户端应用服务器140。数据捕获装置110a和110b可以是可连接到计算机系统120a和120b且可捕获一些类型的多媒体数据(例如，视频、音频和/或静止图像)的任何所述装置。举例而言，数据捕获装置110a和110b可以是网络照相机、数字静止照相机、麦克风等。在一个实施例中，数据捕获装置110a和/或110b是Logitech，Inc.(Fremont，CA)的QuickCam

网络照相机。

主机120a和120b是常规的计算机系统，其可各自包括可耦接到计算机系统的计算机、存储装置、网络服务连接和常规输入/输出装置(如显示器、鼠标、打印机和/或键盘)。在一个实施例中，计算机还包括常规操作系统、输入/输出装置和网络服务软件。另外，在一个实施例中，计算机包括可与客户端应用服务器140通信的客户端应用软件。网络服务连接包括允许连接到常规网络服务的那些硬件和软件组件。举例而言，网络服务连接可包括到电信线的连接(例如，拨号、数字用户线路(“DSL”)、T1或T3通信线路)。主机计算机、存储装置和网络服务连接可从(例如)IBM公司(Armonk，NY)、Sun Microsystems，Inc.(Palo Alto，CA)或Hewlett-Packard，Inc.(Palo Alto，CA)购得。

网络130可以是任何网络，如广域网(WAN)或局域网(LAN)或任何其它网络。WAN可包括因特网、因特网2和其类似物。LAN可包括内网，其可以是基于(例如)TCP/IP属于一个组织且仅可由组织的成员、员工或经授权的其它人访问的网络。LAN也可以是如Novell公司(Provo，UT)的Netware^TM或微软公司(Redmond，WA)的WindowsNT的网络。网络120也可包括市售的基于预订的服务，如美国在线公司(Dulles，VA)的AOL或微软公司(Redmond，WA)的MSN。

一些客户端应用程序需要客户端应用服务器140。下文中参考图2A论述客户端应用程序。

图2A说明上述系统100的一侧的一个实施例。如上所述，这包含数据捕获装置110和主机120。为了容易论述，以下论述参考视频数据的捕获和处理。如上所提及，请注意，其它类型的多媒体数据(例如，音频和静止图像数据)在多种实施例中以多种方式处理。在一个实施例中，由数据捕获装置所需的驱动程序210、视频捕获应用程序接口(API)220和用户选择来使用的客户端应用程序230存在于主机120上。

上文已参考图1描述了数据捕获装置110和主机120。驱动程序210是控制数据捕获装置110的程序。驱动程序210可与主机上的操作系统一起出现，或可需要从因特网上下载，或从数据捕获装置110所附的CD下载等。驱动程序210用作视频捕获装置110与主机120上的操作系统之间的翻译程序。每一视频捕获装置110具有其自己的专用命令集，仅其驱动程序210知道这个专用命令集。另一方面，大多数操作系统通过使用通用命令访问视频捕获装置110。因此，驱动程序210需要从主机120上的操作系统接受通用命令，且将它们翻译成视频捕获装置110可理解的专用命令。驱动程序210也用作视频捕获装置110与使用数据捕获装置110的视频捕获API220之间的接口。

视频捕获API220是达成驱动程序210与客户端应用程序230之间的分离的方式。在一个实施例中，视频捕获API220是微软公司(Redmond，WA)的DirectShow。在另一实施例中，视频捕获API220是用于Windows的视频(VFW)，其也是微软公司(Redmond，WA)的。在又一实施例中，视频捕获API220是微软公司(Redmond，WA)的实时通信(RTC)堆栈。

客户端应用程序230可以是使用视频捕获装置110的任何程序。举例而言，在一个实施例中，客户端应用程序230是即时通讯软件(IM)。当前可用的IM程序的一些实例是微软公司(Redmond，WA)的通讯软件、America Online，Inc.的美国在线即时通讯软件(AIM)和Yahoo！Inc.(Sunnyvale，CA)的

即时通讯软件。在另一实施例中，客户端应用程序230是视频会议应用程序，如微软公司(Redmond，WA)的NetMeeting。在又一实施例中，客户端应用程序230是音频通讯应用程序，如Skype Group(Luxembourg)的Skype。

图2B是说明上文参考图2A所述的系统中的数据流的方框图。

在这个图中所说明的实施例中，视频数据由数据捕获装置捕获，传递给驱动程序210，再传递给视频捕获API 220，且然后传递给客户端应用程序230。注意，如上所提及，数据流的方向可相反，即，从客户端应用程序230到输出装置(例如，连接到主机120的记录装置)。

可看出在用户模式与内核模式之间绘有区别。将参考图3B更详细描述这些。

图3A是说明根据本发明的一实施例的系统的方框图。其包含视频捕获装置110、驱动程序210、用户模式视频处理层(UMVPL)310、视频捕获API 220和客户端应用程序230。

数据捕获装置110、驱动程序210、视频捕获API 220和客户端应用程序230已在上文中加以描述。通过比较图3A和图2A，可看出UMVPL 310是一新层。在一个实施例中，UMVPL 310插入驱动程序210与客户端应用程序230之间。UMVPL 310位于数据源110与客户端应用程序230之间，且UMVPL 310经配置以透明地处理数据流。这允许客户端应用程序230不知道来自数据源110的数据流的原始格式/内容。因此，根据本发明的一实施例的系统可接受各种格式和内容，且视用户所需来处理并/或修改多媒体数据。

请注意，关于UMVPL 310的论述可应用于除了视频数据外的多媒体数据。举例而言，用户模式音频处理层(UMAPL)将非常类似地起作用，只需做对于所属领域技术人员而言显而易见的修改。

在将修改音频数据的一个实施例中，UMVPL 310可由UMAPL(用户模式音频处理层)替代。在另一实施例中，UMVPL 310可由UMAPL补充。UMVPL/UMAPL是视用户所需修改数据流的地方。这使视频/音频更有吸引力且使用起来更有趣。举例而言，UMVPL 310可执行色彩校正、图像变形和改变、色彩键控、视频化身、界面附件(faceaccessory)、流预览、电子欺骗或影响视频数据流所需的任何特殊效果(例如，增加雨点效果)等。UMAPL可执行(例如)通道混合、静音缓冲、噪音抑制、噪音取消和凹口过滤、变形、形态变化、电子欺骗或影响音频数据流所需的任何特殊效果。在一个实施例中，用户可通过图形用户接口或其它接口输入他或她对用以对多种类型的流执行的处理类型的优先选择。

在一个实施例中，定义一接口以允许第三方开发用于专有处理框架的组件或插件程序。在一个实施例中，第三方实施独立于它们将运行的平台。在一个实施例中，插件程序可利用UMVPL 310登记一个或一个以上的视频和/或音频效果。因此，UMVPL 310可用于使插件程序的概念能够应用于透明视频和/或处理。

图3B是说明根据本发明的一实施例的系统中的数据流的方框图。除上文关于图2B所论述的组件外，其包括进程创建监控器320、注入器服务330和注入器钩子动态链接库(Injector Hook Dll)340。

如上文参考图2B所述，视频数据流在一个实施例中由视频捕获装置110产生，且经处理，且最终输出到客户端应用程序230。更一般地，根据本发明的多种实施例的系统从源接受多媒体数据流，处理所述流，且将结果输出到数据槽。多媒体数据源的实例包括如麦克风、独立视频照相机、网络照相机、嵌入视频照相机中的麦克风、音频传感器和/或其它视频/音频捕获装置之类的外围装置。数据也可由客户端应用程序230或转换程序提供。数据流可包含文件，且从如磁带、磁碟、闪存或智慧型驱动器之类的便携式存储媒体，CD-ROM、DVD或其它磁性、光学、临时计算机或半导体内存提供，且经由模拟8或16或更多的引脚端口或并行、USB、串行、防火墙(IEEE 1394)或SCSI端口接收。或者，其可经由Bluetooth^TM/IR接收器所提供的无线连接、无线USB或在标准或定制计算机上提供的多种输入/输出接口提供。数据流可经调度到数据槽，如文件、扬声器、客户端应用程序230或装置(上文关于端口、存储器和总线的相同论述应用于数据槽)。客户端应用程序230可以是使用者，它是源/数据槽110的客户端。这可包括：重放/记录应用程序，如微软公司(Redmond，WA)的Windows媒体播放器(WindowsMedia Player)；通信应用程序，如微软公司(Redmond，WA)的Windows通讯软件(Messenger)；音频编辑应用程序；视频编辑应用程序；或任何其它音频或其它类型的通用或专用多媒体应用程序。上文在图2A的内容中已描述了客户端应用程序。

数据流可以是多种格式中的任一种。举例而言，音频流可以是PCM格式或非PCM格式、wav格式、mp3格式、压缩或非压缩格式、单声道、立体声或多通道格式，或具有给定样本速率集合的8位、16位或24位。数据流可用模拟形式提供，且可通过模拟到数字的转换程序，且可存储在磁性媒体上或任何其它数字媒体存储器上，或可包含数字信号。视频流也可以是压缩或非压缩的，且可以是多种格式中的任一种，包括RGB、YUV、MJPEG、多种MPEG格式(例如，MPEG 1、MPEG 2、MPEG 4、MPEG 7等)、WMF(Windows媒体格式)、RM(实媒体)、Quicktime、冲击波和其它格式。最后，数据也可以是AVI(视频音频交错)格式。

再次参考图3B，当客户端应用程序230打开时，便在系统中创建了一进程。进程创建监控器320监控所创建的每一进程，且只要其检测到新进程的创建便通知注入器服务330。这个注入器服务330然后将注入器钩子的库(注入器钩子动态链接库340)注入到这个新的进程中。以这种方式，可确保每一进程被注入注入器钩子动态链接库340。然后，这些钩子在视频数据到达器目的地之前经由UMVPL 310重新路由每一视频数据流。在一个实施例中，注入器钩子动态链接库340使用特定组件来拦截驱动程序210与视频捕获API 220之间的通信量。在一个实施例中，这些组件包括KsUser.dll、Kernel32.dll和NtDll.dll。KsUser.dll是实施Windows内核流组件的低级别接口的共同库，Kernel32.dll是实施大多数低级别Win32函数的共同库，特定而言，是实施在一个实施例中拦截的CreateFile()和DeviceIoControl()函数的共同库。NtDll.dll是用作Windows中的内核世界的网关的共同库。在一个实施例中，注入器钩子动态链接库340拦截KsUser.dll与NtDll.dll之间和Kernel32.dll与NtDll.dll之间的调用。这是如何获得对视频数据的访问和检测对打开和关闭装置/流的请求。

在一个实施例中，同时提供音频和视频数据。在所述实施例中，UMVPL 310和UMVPL两者都存在，且视数据类型而定，经由注入器钩子将数据路由到UMAPL或UMVPL 310。即，访问数据类型，且将音频数据路由到UMAPL，且将视频数据路由到UMVPL 310。

图4A、4B和4C是描绘根据本发明的一实施例在一系统中的特定实例的流程图，其以打开客户端应用程序230起动，然后打开视频流，再到关闭所述流。由客户端应用程序230、进程创建监控器320、注入器服务320和UMVPL 310以及捕获装置110执行所展示的步骤。

从图4A中可看出，当打开客户端应用程序230(步骤410)时，由进程创建监控器320检测进程的创建(步骤420)。然后由注入器服务330将钩子注入到进程中(步骤430)。当客户端应用程序230请求捕获装置打开视频流(步骤435)时，UMVPL 310拦截这个请求，且然后将这个请求传输到捕获装置以打开视频流(步骤440)。捕获装置110打开视频流(450)。也报告视频流已打开(步骤455)。这个报告也被拦截(步骤457)，且由UMVPL 310执行适当的设置。然后UMVPL 310像客户端应用程序报告打开的流(步骤460)。客户端应用程序因此接收视频流正被打开的报告(步骤465)。

现参考图4B，可以看出客户端应用程序230现请求个别视频帧(步骤470)。这个请求再次由UMVPL拦截(步骤475)，且然后发送到视频捕获装置110。当视频捕获装置接收这个请求(步骤477)时，其发送个别视频帧(步骤480)。这些个别视频帧由UMVPL 310拦截(步骤485)，且由UMVPL 310处理(步骤487)。所述处理(步骤487)的实例已在上文中提供。然后将经处理的个别帧发送到客户端应用程序230(步骤490)。客户端应用程序接收这些经处理的帧(步骤492)。

参考图4C，可以看出客户端应用程序230请求捕获装置110来关闭视频流(步骤492)。这个请求再次由UMVPL 310拦截且经传输到捕获装置110(步骤494)。然后由视频捕获装置110关闭视频流(步骤495)，且报告视频流已被关闭(步骤497)。这个报告由视频流拦截(步骤497)，且视需要执行清除(步骤498)。最后，由UMVPL 310报告视频流已被关闭(步骤499)，且客户端应用程序230接收这个报告(步骤500)。

图5是大体识别根据本发明一实施例的一系统执行的用于所创建的每一进程的步骤。由进程创建监控器320检测所创建的任何进程(步骤510)。然后由注入器服务330将注入器钩子动态链接库340注入进程中(步骤520)。然后由UMVPL 310拦截在进程控制下的多媒体数据(步骤530)。然后由UMVPL 310处理这些多媒体数据(步骤540)。然后将经处理的多媒体数据提供给数据槽(步骤550)。

为了支持各种捕获方法，在一个实施例中，需要将视频拦截机制(拦截器)引入可能的最低级别。将必须设计用于每一捕获方法的另外的定制拦截方法，因此大大增加了解决方案的复杂性。

为了这个原因，在一个实施例中，就在将数据发送到捕获驱动程序或从捕获驱动程序发送数据之前，在内核边缘拦截视频通信量。这个用户模式空间中的最低点允许监控多种不同视频捕获方法。因为所有的WDM视频捕获装置使用相同的通讯协议来将数据返回给用户模式客户端应用程序，所以这可起作用。

在一个实施例中，拦截机制监控来自上述客户端应用程序的装置和引脚(pin)创建请求；判定所创建的引脚中哪些是所关注的引脚；通过拦截发送到这些引脚的装置I/O控制来监控到这些引脚的通信量；且当引脚关闭时停止监控所关注的引脚。

在一个实施例中，当监控到一引脚的通信量时，注意力集中到创建格式、“设置格式请求”和读/些请求上，这些事件的每一者对UMVPL如何处理视频缓冲器和何时处理视频缓冲器都有直接影响。

上述拦截机制时解决方案的第一阶段。在一个实施例中，第二阶段是重新创建UMVPL可连接的环境。在一个实施例中，建构所述环境以优选仿真其当前连接的ksproxy主机，以最小化所需的对UMVPL的改变且排除对处理组件的必要改变。因此在某种程度上，这个解决方案重新创建了小型DirectShow层，以使得能够重新利用用于其它应用程序的UMVPL实施，而不需要任何显著改变。

DirectShow(有时简称为DS或DShow)是由微软产生的用于软件开发的应用程序设计接口，以利用媒体文件执行多种操作。它是微软的早期Windows视频技术的替代。基于微软Windows组件对象模块框架，DirectShow跨越许多微软程序设计语言提供用于媒体的共同接口，且DirectShow是可扩展的基于过滤器的框架，其可在用户或开发者命令时一经请求便呈现或记录媒体文件。DirectShow开发工具和文档经分配而作为微软平台SDK的部分。如Windows媒体播放器之类的应用程序使用DirectShow或其变体来显示文件或URL的内容。DirectShow的最显著的竞争是RealNetwork的Helix框架和苹果计算机的QuickTime框架。

在一个实施例中，拦截机制导致小型DirectShow层来为UMVPL初始化适当请求，以处理预期的视频流。

拦截器

将创建一进程时，实际上不可能确切知道那个进程是否将要捕获视频。存在确定特定进程将很可能捕获视频的信号，但是不存在知道给定进程将明确地不捕获视频的方式。因此，在一个实施例中，将拦截机制插入系统上几乎所有的进程中，其中异常很少。每一进程中这个拦截机制的安装称为“注入码(injecting code)”。在一个实施例中，为了解决上述问题，完整的拦截机制包含3部分：

1.内核驱动程序，其监控系统中进程创建，且当创建了新进程时通知客户端服务(进程创建监控驱动程序)。

2.系统服务，当创建了新进程时其接受来自内核驱动程序的通知，且然后在新近创建的进程中起始该码注入机制(“注入器服务”)。

3.注入器钩子动态链接库，其表示由注入机制注入的码。这个动态链接库(DLL)负责决定是否应钩住进程，若需要则将拦截钩子安装在进程中，且监控通过所安装的钩子的视频通信量。那个DLL也含有小型DirectShow层，但是这个层本身不属于拦截机制。

在这个实施例中，可支持任何用户模式视频捕获方法，只要它使用ofKsUser.dll来在WDM内核装置上创建视频捕获引脚。所有当前已知的视频捕获方法属于这个类别。如果一些将来的视频捕获方法不属于这个类别，那么将也钩住新的版本以扩展对这个新接口的支持。

图6是比图3B更详细地展示关于注入器钩子部分的架构和其关系的多种组件的图。

数据流

图7是展示根据本发明的一实施例的视频帧的典型数据流的图。

进程创建监控驱动程序330负责监控系统中新进程的创建，且负责向客户端系统服务报告所述创建。这个驱动程序不是WDM驱动程序，而是纯NT驱动程序。可将其安装为具有SERVICE_DEMAND_START起动类型的SERVICE_KERNEL_DRIVER。这个驱动程序在客户端服务起动时将由客户端服务起动。

在一个实施例中，为注入器服务330和驱动程序320通信而定义一简单协议，其包含两个IOCTL码。在一个实施例中，第一个IOCTL码仅使用包含两个DWORD的输出缓冲器。第一个DWORD将在完成后接收新进程的PID，且第二个DWORD将在完成后接收进程主线程的线程ID。它总是异步完成。在一个实施例中，第二IOCTL码仅使用输入缓冲器。这个输入缓冲器包含单个DWORD，其为需要释放的进程的PID(见下文)。这个请求总是同步完成。

在一个实施例中，协议使用如下。客户端服务将许多第一IOCTL码排队到驱动程序中。所有的请求保持挂起，直到创建了进程为止。驱动程序在每次创建进程时，从队列中取出一个挂起的IOCTL(如果不存在挂起的IOCTL，那么立刻从进程创建调回返回)，获得当前的线程id(其为进程初始线程id)，且将PID和线程id两者存储到请求的输出缓冲器中。然后它完成请求。之后，它仍不从进程创建调回返回。它首先在堆栈上创建一事件，将这个事件存储到由PID做索引的链接列表中，且等待预定时间量(例如，1秒)来完成事件。然后它将事件从链接列表中移除，且从调回返回。

只要第一个IOCTL码完成，服务将采取必要的行动来将所述码注入到新进程中，且其然后将发送第二IOCTL码到驱动程序来让它知道它已完成了那个进程上的工作。一旦接收到那个IOCTL，驱动程序将在事件链接列表中查找与PID(存储在请求中)相关联的事件，且如果驱动程序找到对应事件，那么驱动程序将用信号通知它，因此释放驱动程序在调回中的等待。然后驱动程序完成IOCTL且返回。

上述协议允许只要新进程起动且给服务一个机会来在任何码有机会进入新进程之前将码注入到那个进程中，便通知客户端服务。这就最小化钩子机制将在其监控末期起动的情况。

如下文所阐释，在一个实施例汇总，保持挂起的所有IRP保持在取消-安全IRP队列中，使得IRP可在任何时候取消，特定而言，在服务进程终止时取消。

当新进程起动时，注入器服务330接收来自内核驱动程序的通知，且然后它在进行创建的进程中起始码注入机制。在一个实施例中，这个服务安装为具有SERVICE_AUTO_START起动类型的SERVICE_WIN32_OWN_PROCESS。在一个实施例中，这个服务仅支持开始和停止，且不支持如暂停之类的其它命令。又在一个实施例中，为了确保在启动进程中足够早地加载这个服务，使得不丢失进程，便将这个服务加入到“AudioGroup”加载顺序群组(Load Order Group)。在任何多媒体活动可在系统上开始之前加载这个群组。在一个实施例中，设置服务在本地系统帐户(Local SystemAccount)中运行。

当服务起动时，在一个实施例中完成的第一件事是起动内核驱动程序服务。在内核驱动程序已起动之后，其打开又驱动程序创建的装置，且然后创建五个线程。每一线程将单个第一IOCTL排队到驱动程序中。在一个实施例中，不传递重叠结构。这将使得在完成一请求之前产生每一线程块。创建5个线程比仅创建一个请求其中多个重叠的请求挂起的情况更有效，因为一个以上的请求可这样同时处理。在一个实施例中，服务然后等待这些请求中的任一者完成。

如果服务需要停止，那么调用CancelIo()来取消并返回所有挂起的IOCTL请求。然后它等待所有的线程完成(在线程的句柄上等待以用信号通知)。在一个实施例中，当线程句柄和装置句柄完成时便关闭它们。

当线程的请求完成时，验证请求的成功完成。如果未成功完成，且如果服务不停止，那么将另一IOCTL重新排队。如果服务停止，那么替代地退出线程。在一个实施例中，mutex(相互排斥对象)用于防止服务运行状态在线程正在处理完成的请求时改变。另外的竞态条件可发生从而导致线程永不终止。

如果请求成功完成，那么码注入机制如下所阐释来初始化，且第二IOCTL请求连同新进程的PID发送到驱动程序。在一个实施例中，如果码注入失败，那么仍然发送第二IOCTL。然后如果服务尚未进入停止状态，那么服务将另一第一IOCTL请求排队到驱动程序中。

这里有在本发明的一个实施例中码注入机制如何工作的阐释：

1.打开具有以下访问权限的目标进程：PROCESS_VM_WRITE、PROCESS_VM_OPERATION、PROCESS_CREATE_THREAD、PROCESS_QUERY_INFORMATION和PROCESS_VM__READ。

2.在远程进程中配置内存组块。这个组块足够大以含有待注入的存根码(stubcode)。在一个实施例中，这可通过使用VirtualAllocEx()来完成。指定MEM_COMMIT和PAGE_EXECUTE_READWRITE。重要的是，将页标记为执行以使它在支持NX技术的处理器上工作。

3.建构小的存根(其将字符串的地址(用以加载的DLL的全路径)压入堆栈)，调用LoadLibraryA()且然后返回从堆栈弹出的四个字节(八个字节用于64为平台)。存根应为其在远程进程上工作而例示化。为了使这个工作，在存根末端包装字符串，且因此字符串的地址易于基于内存在远程进程中所配置的地方而计算。LoadLibraryA()的地址在所有版本的Windows上这时的所有进程中相同。这是因为Kernel32.dll总是在进程空间中的相同偏移处加载。这可在系统范围优化时完成以加速进程的加载，因为所有进程给出或采用所有加载Kernel32.dll中的少数。如果这将改变，那么它将易于使用PSAPI重新基于这个地址来获得目标进程的Kernel32.dll基地址。因此为了在远程进程中获得LoadLibraryA()的地址，在当前进程中使用GetProcAddress()。使用GetModuleHandle()来找Kernel32.dll。

4.使用WriteProcessMemory()复制远程进程中的存根。

5.使用CreateRemoteThread()创建远程进程中的线程。那个线程应在存根开始处起动。

6.通过在线程句柄上等待来等待线程完成，且然后关闭线程句柄。

7.通过调用VirtualFreeEx()、传递MEM_RELEASE来释放远程内存。

8.关闭进程句柄。

上述码执行远程进程中的加载库，因此导致所选的DLL(这里是注入器钩子DLL)在远程进程中加载。DLL的DLLMain函数从那里接管，从而将所有必要的钩子插入远程进程中(见下一节)。当目标进程消失时，所注入的DLL将自动卸载。

在一个实施例中，如果发现服务不能在启动进程中足够早地加载使得不丢失所关注的任何进程，那么服务经修改以在五个线程已起动之后通过枚举所有现有进程来起动。在PSAPI API的情况下服务这样做。然后服务忽略器自己的进程和系统进程，且然后继续钩住所有其它进程。

注入器钩子动态链接库340是由注入器服务在每一进程注入的DLL。这个DLL负责决定是否应钩住进程，若需要则将拦截钩子安装在进程中，且监控通过所安装的钩子的视频通信量。那个DLL也含有小型DirectShow层。那个DLL安装在预定位置中，使得注入器服务可易于定位其且为其建置全路径字符串。

在一个实施例中，这个DLL具有三个不同的部分：DLLMain起动码，其负责决定DLL是否应保持钩住进程中适当API和进行多种其它初始化/清除任务；小型DirectShow层码；和API钩子码。

DLLMain起动码执行了DLL_PROCESS_ATTACH中的大多数工作。一些额外的清除工作在DLL_THREAD_DETACH和DLL_PROCESS_DETACH中完成。在DLL_THREAD_ATTACH中不进行工作。

在DLL_PROCESS_ATTACH中，完成下列工作：

1.调用GetProcessWindowStation()，其后跟随GetUserObjectInformation()和UOI_NAME以获得Windows Station的名称。如果不是“WinSta0”，那么DLLMain()应返回FALSE，从而导致库卸载。

2.初始化所监控的引脚和过滤器链接列表。

3.在Kernel32.dll(图6中的6l0)中和KsUser.dll(612)中安装钩子。为了获得对两个DLL的访问，使用LoadLibrary()而不是GetModuleHandle()。GetModuleHandle()仅与已加载的模块一起工作，而更重要地不保证模块将保持加载。然后通过修补如下的两个模块的导入表来安装下列钩子。对于Kernel32.dll钩子，修补ntDeviceIoControlFile()、ntCreateFile()和ntClose()。对于KsUser.dll钩子，修补ntCreateFile()。这里的钩住涉及利用具有存在于我们的注入器钩子动态链接库中的相同原型的函数地址改变导入表中的这些函数的地址。这些函数将完成它们必须完成的事(见下文)，且然后调用最初在导入表中的原始处理程序。

4.视需要初始化任何其它内部结构。

5.返回TRUE。

在DLL_PROCESS_DETACH中，执行下列工作：

1.清空所监控的引脚和过滤器链接列表，从而处理对所有相关对象的毁坏，如我们是否已检测ntClose()。

2.通过恢复导入表中的原始处理程序，并在每一有关DLL上调用一次FreeLibrary()以撤消我们先前对LoadLibrary()的调用，使所有经钩住的函数脱钩(确定我们曾在DLL_PROCESS_ATTACH中成功钩住函数)。

3.视需要释放所有其它资源。

4.返回TRUE。

小型DirectShow层：

如上文所说明，本解决方案的目标是重新创建一与UMVPL过去所见一致的环境，以便可在无需显著改变的情况下把UMVPL定位于所述环境中。为此，注入器钩子DLL可创建三个对象(C++类)，所述对象得自若干个标准DirectShow接口。一个对象仿真一过滤器对象，另一个仿真一引脚对象，且最后一个仿真一媒体样本。

过滤器对象得自IUnknown、IKsObject、IKsControl、IKsProperty和IBaseFilter。引脚对象得自IUnknown、IKsObject、IKsControl、IKsProperty、IPin和IMiniDShowPin。媒体样本对象得自IUnknown和IMediaSample。

IMiniDShowPin接口是专有的。因为其只在局部使用，所以其不需要IDL描述。其定义为抽象类。其包含以下方法：

1.HRESULT SetDataFormat(AM_MEDIA_TYPE*pAMMediaType)。这种方法记住当前媒体格式并调用UMVPL中的IKsDataTypeHandler::KsSetMediaType()。

2.HRESULT DataReceived(KSSTREAM_HEADER*pStreamHeader)。这种方法制作一媒体样本对象并然后调用UMVPL中的IKsDataTypeHandled::KsCompleteIoOperation()。

3.HRESULT DataSent(KSSTREAM_HEADER*pStreamHeader)。这种方法制作一媒体样本对象并然后调用UMVPL中的IKsDataTypeHandled::KsPrepareIoOperation()。然后，其通过释放其IMediaSample接口来毁灭所述媒体样本。

以下是要实施的标准接口和方法的例子。

接口实施的方法

IUnknown        AddRef()，Release()，QueryInterface()

IKsObject      KsGetObjectHandle()

IKsProperty     Set()，Get()，QuerySupported()

IKsControl      KsProperty()，KsMethod()，KsEvent()

IBaseFilter     不需要实施方法。

IPin            QueryDirectionQ，QueryPinInfo()

IMediaSampleGetPointer()，GetSize()，IsPreRoll()(总是只返回S_FALSE)，GetMediaType()，SetMediaType()，GetMediaTime()，SetMediaTime()

当创建了过滤器对象时，其接收对下部对象的句柄。这允许其实施其需要实施的接口。用参考计数一来创建所述过滤器对象。为了删除所述对象，只要通过把所述对象投到其接口之一并调用interface->Release()从而导致对象参考计数到达0来释放其接口的任一个。

当创建了引脚对象时，其接收对下部对象的句柄、对下部过滤器对象的IBaseFilter的指针、当前媒体格式(AM_MEDIA_TYPE)和引脚索引(其用于得到引脚名称和方向(当需要时))。这允许其实施其需要实施的接口。用参考计数一来创建所述引脚对象。为了删除所述对象，只要通过把所述对象投向其接口之一并调用interface->Release()从而导致对象参考技术到达0来释放其接口的任一个。当删除了所述对象时，其释放在其构造函数(constructor)中接收的IBaseFilter接口。同样，当创建了所述对象时，其通过调用CoCreateInstance且pUnkOuter设置为引脚对象的IUnknown从而请求UMVPL对象的IUnknown来与UMVPL对象聚集。记住把对于未知接口的所有QueryInterface()请求传递到UMVPL的IUnknown，以使聚集完全。当毁灭了引脚对象时，释放对已聚集的IUnknown对象的IUnknown的指针。另外，在创建时也查询UMVPL的IKsDataTypeHandler接口。其用来实施IMiniDShowPin接口。在一实施例中，立刻释放这个接口以便保持参考计数。

当创建了媒体样本对象时，其接收缓冲器地址、缓冲器大小、媒体类型和样本媒体时间。这允许其实施其需要实施的接口。用参考计数一来创建所述媒体样本对象。为了删除所述对象，只要通过把所述对象投向其接口之一并调用interface->Release()从而导致对象参考计数到达0来释放其接口的任一个。

API钩子：

在一实施例中，有四个API钩子：Kernel32.dll中的ntCreateFile()、KsUser.dll中的ntCreateFile()、ntDeviceIoControlFiIe()和ntClose()。当调用对于Kernel32.dll的ntCreateFile()钩子时，所述调用到达标准NtDU.dll(图6中的614)实施。如果其返回失败，那么不再做什么。如果其成功，那么考虑OBJECT_ATTRIBUTES结构中的RootDirectory句柄。如果其为NULL，那么考虑OBJECT_ATTRIBUTES结构的ObjectName字段中的文件名。如果所述名称含有对于KSCATEGORY_VIDEO或对于KSCATEGORY_CAPTURE的GUID，那么继续，否则不再做什么。使用返回的句柄，发送Device IOCTL以查询对象的KSPROPERTY_TOPOLOGY_CATEGORIES性质。如果请求失败，那么不再需要做什么。如果其成功，那么进行检查，看是否KSCATEGORY_VIDEO和KSCATEGORY_CAPTURE都存在。如果不是，那么不再做什么。如果它们存在，可能所述对象是Video Capture KS过滤器对象，因此记住所述句柄以便可以监控所述对象。在一实施例中，这是通过在小型DirectShow层中创建一过滤器对象来完成的。然后把这个对象投到IBaseFilter中(其中已经有参考计数一)，把句柄和IBaseFilter接口存储在一链接列表中(“过滤器对象链接列表”)。然后返回。

当调用对于KsUser.dll的ntCreateFiIe()钩子时，其用信号通知已创建Ks对象。在一实施例中，所述调用到达标准NtDll.dll实施。如果其返回失败，那么不再做什么。如果其成功，那么考虑OBJECT_ATTRIBUTES结构中的RootDirectory句柄。如果其为NULL，那么不再做什么。如果其不是NULL，那么进行检查，看过滤器对象链接列表中是否能找到所述句柄。如果不能，那么不再做什么。如果找到，那么考虑OBJECT_ATTRIBUTES结构中的ObjectName字段。在一实施例中，这个文件名包含所有需要的信息。其结构为：GUID串继之以二进制结构。如果GUID不是KSNAME_Pin，那么这不是引脚创建且不再做什么。另一方面，如果GUID是KSNAME_Pin，那么考虑之后的二进制结构。在这种情况下，其应为KSPIN_CONNECT。如果大小错误，那么不再做什么。提取KSPIN_CONNECT结构中的引脚索引(PinId)。最后，从KSPIN_CONNECT之后的KSDATAFORMAT结构提取创建格式(并存储在AM_MEDIA_TYPE中)。如果大小错误，那么不再做什么。这时，可得到创建引脚对象所需要的所有信息：句柄、相应过滤器对象的IBaseFilter(在将其交给引脚对象构造函数前调用其上的AddRef())、引脚索引和当前媒体格式。把这个对象投到IMiniDShowPin中(其中已经有参考计数一)，且然后把IMiniDShowPin和引脚句柄存储在一链接列表(“引脚对象链接列表”)中。如果这是引脚对象链接列表中的第一个对象，那么在初始化大小MAXIMUM_WAIT_OBJECTS的装置IOCTL事件阵列(在一实施例中，所有事件都是手动的)和有关的结构阵列(见下文)之后起动装置IOCTL线程。然后返回。

当调用ntClose()钩子时，进行检查，看句柄是否在两个链接列表中的任一个中。如果是，那么调用COM接口上的Release()，移除链接列表纪录，且然后删除纪录。如果这是引脚对象链接列表的最后一个对象，那么停止IOCTL线程。在一实施例中，这是通过用信号通知IOCTL事件阵列的第一个事件(保留来用于终止所述线程)并在线程句柄上等待以用信号通知来完成的。然后关闭线程句柄，并且也关闭装置IOCTL事件阵列中的所有事件。另外，也按需要释放所有有关的结构阵列。最后，调用NtDll.dll中的原始ntClose()实施并返回。

当调用ntDeviceIoControlFile()钩子时，考虑句柄。如果句柄不在引脚对象链接列表中，那么调用NtDll.dll中的原始实施并返回。如果句柄是所监控引脚之一，那么进一步考虑IOCTL请求。如果其不是设置格式请求(IOCTL_KS_READ_STREAM或IOCTL_KS_WRITE_STREAM请求)，那么调用NtDll.dll中的原始实施并返回。如果其是设置格式请求，那么调用NtDll.dll中的原始实施，且如果成功便从所述请求提取格式并调用IMiniDShowPin::SetDataFormat()来更新UMVPL和有关的COM对象中的格式。然后返回。如果其是IOCTL_KS_WRITE_STREAM请求，那么为所述请求(可能为多个)中存在的标头的每一个调用IMiniDShowPin::DataSent()。然后调用NtDll.dll中的原始实施并返回。最后，如果其是IOCTL_KS_READ_STREAM请求，那么调用NtDll.dll中的原始实施，且如果其成功便为所述请求(可能为多个)中存在的标头的每一个调用IMiniDShowPin::DataReceived()。然后返回。

在某些情况下，请求可为异步的。在某些情况下，(例如IOCTL_KS_WRITE_STREAM)是否在进行请求之前完成所述处理无关紧要。然而，在其他情况下，(例如IOCTL_KS_READ_STREAM)这是重要的。在一实施例中，按以下方式解决这个问题：如果在事件参数中有事件句柄，那么用特殊事件替换它(所述事件是从装置IOCTL事件阵列分配的。如果没有可用事件，那么对这个请求不再做什么)，且把原始事件句柄、IoStatusBlock地址、引脚句柄、操作类型(读取流或设置格式)和所需信息的复本存储在附有所述特殊事件的结构中。然后调用NtDll.dll中的原始实施。如果事件参数中没有事件句柄，那么按照以上所指定的同步地完成所述请求。

为使上述起作用，需要一装置IOCTL线程。在一实施例中，按照以上所定义那样起动和停止所述线程。所述线程同时在装置IOCTL事件阵列的所有事件上等待而没有超时(timeout)。如果其是第一个事件，那么所述线程重设所述事件并退出。如果其是任何其他事件，那么首先重设所述事件。然后检查IoStatusBlock，且如果IOCTL成功便检查附有所述事件的数据并按照以上在同步描述中描述的那样完成后IOCTL操作。如果IOCTL失败，那么不进行后操作。然后用信号通知原始事件，且把特殊事件标记为可用于另一IOCTL。最后，所述线程回到在所有事件上等待。

应注意，在一实施例中，每当为了使用或删除过滤器或引脚对象链接列表中包含的COM接口而查找所述列表时，用一mutex锁定所述列表，直到完成COM接口上的操作后才将其释放。否则COM接口在使用的同时可能被删除，从而导致各种有趣的系统崩溃。

虽然已说明并描述本发明的特定实施例和应用，应理解本发明并不限于本文中所揭示的精确构造和组件，且在不背离如以上权利要求书中定义的本发明的精神和范围的情况下，可对本发明的方法与装置的排列、操作和细节进行所属领域的技术人员将明了的修改、改变和变化。举例而言，根据本发明的系统可用于操纵/处理静止图像媒体。另一个例子是在任何给定时间可存在一个以上的多媒体数据流，其中不同流包括不同类型的多媒体数据(例如音频和视频流)。在这种情形中，可同时使用两个不同的处理层(例如UMAPL和UMVPL)。

Claims (22)

1.一种用于透明地处理多媒体数据的系统，包括：

一用于提供多媒体数据的数据源；

一用于接收所述多媒体数据的数据槽；

一用于检测每一已创建进程的进程创建监控器；

一用于在每一检测到的进程注入至少一钩子的注入服务；和

一用户模式处理层，所述至少一钩子把所述多媒体数据重新定向到所述用户模式处理层，且

其中所述多媒体数据在其到达所述数据槽之前被透明地处理。

2.如权利要求1所述的系统，其中所述注入服务热修补内存中的软件。

3.如权利要求1所述的系统，其中只对所述进程的服务调用的一子集插入钩子。

4.如权利要求1所述的系统，其中所述多媒体数据是视频数据，且正好在从所述数据源向一捕捉驱动程序发送所述数据之前或正好在所创建的所述进程中的任意一个从所述捕捉驱动程序接收所述数据之前，在内核的边缘拦截所述视频数据。

5.如权利要求4所述的系统，其中所述视频数据通过以下步骤被拦截：

监控来自以上所创建的所述进程的装置和引脚创建请求；

决定哪些已创建引脚是所关心的；

通过拦截发送到所关心的引脚的装置输入/输出控制来监控流向这些引脚的通信量；

当所述所关心的引脚关闭时停止监控所述引脚。

6.如权利要求5所述的系统，其中所述监控流向引脚的通信量的步骤进一步包括：

监控创建格式、“设置格式”请求和读/写请求。

7.如权利要求1所述的系统，其中所述多媒体数据是视频数据。

8.如权利要求2所述的系统，其中所述数据源是一网络照相机。

9.如权利要求1所述的系统，其中所述多媒体数据是音频数据。

10.如权利要求9所述的系统，其中所述数据源是一麦克风。

11.如权利要求1所述的系统，其中所述多媒体数据是静止图像数据。

12.如权利要求1所述的系统，其中所述数据槽是一客户端应用程序。

13.如权利要求12所述的系统，其中所述客户端应用程序是一即时通讯应用程序。

14.一种用于处理多媒体数据的方法，其中所述多媒体数据由一数据源提供，且所述多媒体数据由一数据槽接收，其中所述处理对于所述数据源和所述数据槽都是透明的，所述方法包括：

检测一创建于所述系统中的进程；

向所述进程中注入至少一钩子；

经由所述至少一钩子把受所述进程控制的所述多媒体数据路由到一处理层；

在所述处理层中处理所述经路由的多媒体数据，

向所述数据槽提供所述经处理的多媒体数据。

15.如权利要求14所述的方法，进一步包括只对所述进程的服务调用的一子集插入所述钩子。

16.如权利要求14所述的方法，其中所述注入步骤包括向内存中的软件提供热修补。

17.如权利要求14所述的方法，其中所述多媒体数据是视频数据，且正好在从所述数据源向一捕捉驱动程序发送所述数据之前或正好在所创建的所述进程中的任意一个从所述捕捉驱动程序接收所述数据之前，在内核的边缘拦截所述视频数据。

18.如权利要求17所述的方法，其中通过以下步骤来拦截所述视频数据：

监控来自以上所创建的所述进程的装置和引脚创建请求；

决定哪些已创建引脚是所关心的；

通过拦截发送到所关心的引脚的装置输入/输出控制来监控流向这些引脚的通信量；

当所述所关心的引脚关闭时停止监控所述引脚。

19.如权利要求18所述的方法，其中所述监控流向引脚的通信量的步骤进一步包括：监控创建格式、“设置格式”请求和读/写请求。

20.如权利要求14所述的方法，其中所述多媒体数据是视频数据。

21.如权利要求14所述的方法，其中所述多媒体数据是音频数据。

22.如权利要求14所述的方法，其中所述多媒体数据是静止图像数据。

Images