专利名称:从不同源向不同客户端应用提供多媒体数据的方法及系统的制作方法
技术领域：
本发明涉及媒体源输入装置，例如麦克风及摄像机，且具体而言涉及媒体源输入装置与应用程序的接口连接。
背景技术：
传统上，当一个应用程序连接至一媒体源时，所有其它应用程序均被禁止使用该媒体源。在一常见的个人算计机情况下，当一应用程序请求与一媒体源进行通信时，所述应用程序会调用驱动文件或动态链接库(DLL或*.dll)文件。通常，一DLL提供一个或多个特定功能且一程序通过创建一通至所述DLL的链接来存取所述功能。DLL也可包含数据。一些DLL配备有操作系统(例如Windows操作系统)并可供用于任一操作系统应用程序。其它DLL是针对一特定应用程序得到写入并加载有所述应用程序(例如一媒体源控制应用程序)。当一媒体源控制应用程序请求连接至一媒体源时，驱动器会进行检查以确认没有其它应用程序已打开所述特定摄像机驱动文件(*.dll)，且若没有其它应用程序已打开，则驱动器将打开所述特定驱动文件。如此一来，此时便通过所打开的媒体源(例如摄像机)驱动文件在媒体源(例如摄像机)与应用程序之间存在一如图1中所见的单线程连接。
图1显示一与一媒体源连接的应用程序，所述媒体源为一摄像机。如图1中所描绘，驱动文件14是通过由发出调用的应用程序10所调用的驱动器12来打开并加载于发出调用的应用程序的存储器中。由于摄像机驱动文件14已被应用程序10打开，因此禁止下一试图调用摄像机的应用程序打开摄像机驱动文件14。与在多个应用程序之间共享一媒体源时发生的冲突相关的问题称作应急问题。由于典型的输入装置驱动器在任何给定时刻只允许一个应用程序使用输入装置数据，因此会存在应急问题。这是因为摄像机驱动文件已加载于第一应用程序的存储器中且无法供另一发出调用的程序存取。因此，每一可能会调用一摄像机的应用程序均必须虑及可能已在使用所述摄像机的另一应用程序的存在。因此，此种应用程序受制于下述需要需要首先进行检查以判定是否执行了已连接至所述摄像机的另一第一应用程序，且若如此，则第二发出调用的程序必须具有允许其协商对所述摄像机的共享的例程。然而，此种共享为一单一瞬时共享，此意味着在能够建立摄像机与第二应用程序之间的连接之前将须中断(即第一应用程序将须关闭或摄像机将须断开)摄像机与第一应用程序之间的连接。还必须通过这两个竞争的应用程序之间的通信来解决权限、优先权及其它安全方面以及适当的错误处理。目前，还没有哪一应用程序甚至尝试着解决这些问题中的任何一个，且因此，如果不能在一发出调用的程序与一摄像机之间建立连接，则由操作系统通过发出相当粗糙且难以辨认的错误消息来解决意外应用程序错误，此使最终用户只能推断出不能建立一适当的连接。充其量，第二发出调用的应用程序会接收到一指示所调用的装置当前正在使用中且不可用的消息。
应用程序的大小、灵活性及可用性一直在不断增大，且目前的趋势是从大的单块式应用程序发展到由许多更小的子程序构成的程序。此种积木式方法提供许多优点，例如易于以后的修改及可配置性。而且，操作系统提供商(例如Microsoft)也已采用此种模块式方法且因此提供许多标准的子程序或目标程序，这些子程序或目标程序处理许多实用型功能，例如将发送至打印机的文件排队及加载并运行打印机驱动器(例如DLL)文件以打印文件。所述驱动(例如DLL)文件本身为目标程序或子程序。此外，为努力实现目标程序与以不同的高级编程语言编写的较小子程序之间的互操作性，操作系统提供商已开发出可在二进制层次上彼此兼容的可执行程序模型。由Microsoft公司开发出的一种这样的二进制码模型为组件对象模型(COM)。COM使程序师能够开发出可由任何适应于COM的应用程序存取的目标程序。虽然可通过从大的单块式应用程序转换成较小子程序及目标程序的集合来实现许多优点，但这些优点必须与因需要附加例程来允许在这些子程序及目标程序之间进行过程间通信而施加的负荷保持平衡。
除复杂性及可用性增大外，多单元应用程序还一直在从单主机站点往多主机多机种网络环境变迁。所以，目前由许多分别以不同的高级编程语言编写并分别驻存于一单独计算机上的不同例程构成的单个应用程序并不陌生，其中所有这些计算机均通过网络彼此连接。在此类实施方式中，对于有效的网络内及网路间及过程间通信的需求可自然而然地形成，从而不利于程序师的编写应用程序的主要任务。程序师还必须处理因在网络中分布应用程序而引起的通信问题。同样，操作系统提供商已认识到此种挑战及潜在的损害并已以各种方式解决此挑战及潜在损害。例如，Microsoft已通过开发出分布式组件对象模型(DCOM)来扩展COM功能性。DCOM是一支持分布于一网络中的目标程序的COM扩展形式。除为COM的扩展形式外，DCOM还提供一处理网络通信协议的细节的接口，以使应用程序设计师能够着重于其开发应用专用程序的主要功能。DCOM经设计以解决企业对分布式组件架构的要求。例如，一企业可能想要建立及采用一用户订单登记应用程序，所述用户订单登记应用程序涉及到数个不同功能领域的，例如税款计算、用户信用验证、库存管理、担保更新及订单登记。通过使用DCOM，所述应用程序可由五个单独组件构成并可在一通过浏览器存取的网络服务器上运行。每一组件均可驻存于一存取一不同数据库的不同计算机上。程序师可着重于应用程序开发且DCOM用于处理应用程序中各单独组件的过程间通信方面。例如，DCOM将处理组件通信与适当队列的整合及一服务器上的组件应用程序与基于HTML的因特网应用程序的整合。
因此，虽然许多计算机系统操作系统提供商正在提供许多标准化的可执行程序模型，但即使这些可执行程序也只能在一对一的基础上介接一媒体源输入装置。一旦链接至一应用程序，一标准化装置驱动文件便不再可供用于另一程序。
一些网络摄像机供应商(例如新加坡的Creative Labs)使用虚拟源概念，但此是通过向用户提供一从中进行选择的多个装置的选项来实现的。举例而言，用户将看到“常规网络摄像机”以及一“虚拟”网络摄像机。如果用户选择“常规”网络摄像机，则其将无法使用某些视频效果。然而，如果用户选择使用“虚拟”网络摄像机，则其可使用某些视频效果。此需要进行不必要的用户干预并可能使用户混淆。此外，此并未解决将视频数据自一个源同时提供至多个客户端应用程序的问题。
此外，当前，无法以一通用方式将多个源无缝地虚拟化成一个源。存在一些其中可以一组合方式输出来自不同源的媒体数据的已知应用程序(例如监视系统)。然而，此只能通过获得并使用专门的且昂贵的硬件来实现或在专用软件应用程序(例如具有专用API)的背景中实现。因此，不存在一种可将来自不同的源的媒体数据组合成单个源而不使用专用硬件且可用于任何应用程序的简单解决方案。
Windows 2000包括一用于虚拟音频的核心模式Windows驱动器模块。客户端是与虚拟音频源而不是与实际源进行通信。多个客户端可自同一音频源接收一音频流。而且，还提供一混频系统驱动器。Microsoft对若干源进行的虚拟化仅限于音频，而且也不允许对多个音频源进行虚拟化以向一个或多个客户端应用程序提供数据。
需要使多个应用程序能够以一种容易且无缝的方式共享单个媒体源输入装置(其最常为摄像机或麦克风)，而无需用户主动地选择一虚拟装置来实现此目的。此外，需要能够将来自多个源的媒体数据组合成单个流，然后使所述流可供一个或多个应用程序以一通用且透明的方式使用，且无需使用任何专用硬件。
发明内容本发明将一可执行过程的特征与使多个应用程序共享单个输入装置(例如摄像机或麦克风)这一需要相结合。例如摄像机或麦克风等输入装置为外围装置，其响应于来自一应用程序的调用而打开并保持打开。本发明提供一种构建成一使多个应用程序能够与单个输入装置进行通信的过程的可执行程序。此是通过为所述实体输入装置创建一虚拟接口(一示例)并将所述输入装置控制可执行程序加载至一过程中来实现。一示例是一加载入存储器中的实体的实际使用及其一副本的最后虚拟形成。所述可执行程序过程用作一服务器，从而使多个应用程序能够介接同一输入装置。此可执行程序-其在本文中称作多实例输入装置控制(MIDC)可执行程序-响应于每一应用程序请求，仿佛所述输入装置是针对所述发出调用的应用程序而打开一般。因此，每一应用程序均能够与所述输入装置示例进行通信而不会中断与同一输入装置进行通信的其它应用程序的运行。换句话说，所述MIIDC通过创建一客户端-服务器架构来将一输入装置虚拟化，在所述客户端-服务器架构中，每一发出调用的应用程序均为一客户端且其中所述MIIDC为服务器，其向每一发出调用的应用程序提供所述驱动文件。
所述MIIDC及用以将一输入装置虚拟化的方法可构建于运行各种操作系统的许多计算平台上。一媒体源输入装置(例如一摄像机或一麦克风)通常介接一主计算机。所述主计算机最常为个人计算机，例如通常可使用的Mac计算机PC。然而，由于技术的进步正使计算装置与通信装置之间的界限变得模糊，因此本文所述的主计算机与一智能主机同义，且本文所述的智能主机是指包括任何具有一处理器、存储器、输入及输出构件、及存储构件的主机的其它实例。智能主机的其它实例-其也同样适于与本发明各实施例结合使用-包括手持式计算机、交互式机顶盒、薄的客户端计算装置、个人存取装置、个人数字助理及因特网设备。
在一种位于一运行基于Windows的常见操作系统的PC主机上的实施方式中，所述(MIIDC)可执行程序可为一DCOM目标程序。DCOM也可充当一使多个应用程序能够与单个输入装置进行通信的接口。所述DCOM接口处理所有介接操作，例如加载、执行、缓冲、卸载及调用所述可执行程序。在所述基于DCOM的实施方式中，所述MIIDC目标程序本身为一DCOM服务器。所述MIIDC程序通过在一构建为一可执行服务器的DCOM目标程序中连接至所述输入装置来起作用。因此，所述MIIDC变成一构建为一可执行程序的DCOM目标程序，此意味着MIIDC为一可由许多应用程序共享的过程一此类似于任何其它操作系统(O/S)过程。通过将所述输入装置存取程序放入一单独的可执行过程中，所述输入装置能够由多个应用程序共享。虽然仅存在所述输入装置的一个示例，但所述DCOM接口在所述应用程序看来仿佛其是恰好为调用所述DCOM目标程序的应用程序打开一般。
MIIDC构建成对于每一实际的硬件输入装置，所述DCOM服务器均创建单个输入装置示例并连接至所述硬件装置。当一应用程序与所述输入装置控制-其为一可执行的DCOM服务器-连接时，所述DCOM服务器会创建一MIIDC示例(及一接口)，以使所述应用程序通过其与所述单个输入装置示例进行通信。所述单个输入装置示例为所述输入装置控制的每一示例提供数据以供输出，从而使多个应用程序能够同时与单个输入装置进行通信。全局设定值是针对具体(MIIDC)示例的。另外，所述输入装置示例受到保护，以使所述输入装置控制程序的多个示例无法执行将会妨碍另一示例中的处理的任务。通过使用此种新的方法，可编写出无需虑及可能已在使用同一输入装置的另一应用程序的存在的应用程序。
本发明的其它方面涉及使一应用程序能够与输入装置服务器可执行程序进行通信的客户端机构。如上所述，所述MIIDC可执行程序构建于一其中每一应用程序均为一客户端的客户端-服务器架构下。自然地，客户端必须能够与服务器进行通信。本发明的方法提供数种使一应用程序能够与所述MIIDC服务器进行通信的机构。在一PC/Windows环境中，一第一客户端侧机构通过一称作输入装置门户的ActiveX控制来传送。一同样处于一PC/Windows环境下的第二客户端侧机构则通过一DirectShowTM视频捕捉源滤波器来传送。
根据所述门户方法的所述客户端侧机构包括与所述MIIDC服务器进行通信并向一应用程序提供用户接口元件。根据所述门户方法，用以将一输入装置虚拟化的所有功能均由所述MIIDC服务器实施，且因此与所述MIIDC服务器进行通信的应用程序将需要进行用户接口编程。为实现此目的，根据所述视频门户方法，提供一模板以使不同的应用程序提供商能够产生其自己的定制的输入装置门户。
根据所述第二种方法(即DirectShow方法)的客户端侧机构利用称作滤波器的标准化DirectShow模块组件。此第二客户端侧机构用一直接与所述MIIDC服务器进行通信的虚拟源滤波器替换标准源(媒体输入)滤波器。所述虚拟源滤波器对于所述MIIDC服务器而言为一客户端。借助此机构，使一DirectShow应用程序无法区分“实际的”与“虚拟”的源滤波器。此第二种客户端侧机构的优点在于所编写的用于在一DirectShow环境中起作用的任何应用程序均将能够很容易地共享一输入装置，而无需进行任何额外的用户接口编程即能够与所述MIIDC服务器进行通信。
一根据本发明一实施例的系统使单个视频流能够无缝地以一种对客户端/应用程序完全透明的方式暴露至所期望多的客户端/应用程序。此外，在一实施例中，一根据本发明一实施例的系统将来自多个装置的视频流组合成单个虚拟流，然后可由所期望多的客户端存取所述单个虚拟流。在上述发明的一些实施例中，每一客户端均可请求一不同的格式及帧速率。此外，在本发明的一些实施例中，将来自一个或多个源的媒体数据提供至一个或多个客户端应用程序的能力对所述应用程序本身而言是完全透明的。另外，在一根据本发明一些实施例的系统中，此实施方式同样对用户透明，因为用户无需选择任何特定虚拟装置等等便可获得此种功能。
为进一步了解本发明的性质和优点，应结合附图来参阅下文说明。
图1为一显示单个应用程序与单个摄像机装置进行通信的现有技术方法的方块图。
图2为一描绘本发明多示例输入装置控制程序的一实施例的方块图。
图3为一显示在一应用程序连接至单个输入装置时所涉及的各步骤的流程图。
图4为一图解说明其中多个源可与多个应用程序进行通信的本发明一实施例的方块图。
具体实施方式图2显示一描绘一处于PC/Windows环境中的本发明多示例输入装置控制程序(MIIDC)的一实施例的方块图。在此实施例中，输入装置为一摄像机，且可执行程序为一DCOM可执行程序服务器。此图式显示多个应用程序如何才能共享单个摄像机。一旦一第一应用程序100请求连接至摄像机108，所述请求即传送至DCOM应用程序接口(API)102。为了更详细地说明DCOM，可参看适当的Microsoft文档或Microsoft网站。DCOM API 102处理DCOM可执行程序的加载并建立一从应用程序到DCOM可执行程序200的连接。DCOM服务器200创建单个摄像机示例106及一第一MIIDC示例104。接下来，DCOM服务器200将单个摄像机示例106连接至摄像机驱动器107，将摄像机驱动器107连接至摄像机装置108并将第一MIIDC示例104与所述单个摄像机示例106连接。摄像机示例106为一介接至实体摄像机装置108的虚拟接口。一实例是一加载入存储器中的实体的实际使用及其一副本的虚拟创建。在此实施例中，全部示例存储器位于可执行程序服务器中。最后，建立连接300，以使客户端应用程序100能够经由新近所例示的DCOM接口(单个摄像机示例)106与摄像机装置108交互作用。
一旦一第二应用程序110请求连接至摄像机108，DCOM服务器200即创建一第二MIIDC示例114，并将其连接至单个摄像机示例106，从而使第二客户端应用程序110能够通过已建立的第二连接310经由单个摄像机示例106与摄像机装置108交互作用。随后的应用程序请求120以及下列等等也通过随后建立的连接320以及下列等等经由DCOM所例示的单个摄像机示例接口106与摄像机装置108交互作用。
图3为一描绘图2所示过程的流程图。一旦一客户端应用程序请求连接至摄像机装置(步骤103)，便将该应用程序的请求发送至DCOM API(步骤203)。接下来，DCOMAPI判定是否加载由DCOM构建的MIIDC可执行程序。通常，第一客户端应用程序使MIIDC可执行程序进行加载。如果MIIDC可执行程序服务器未得到加载，则DCOMAPI接受该请求并使DCOM服务器加载由DCOM构建的MIIDC可执行程序服务器(步骤403)。接下来，MIIDC服务器创建一输入装置控制示例(步骤503)。如果MIIDC可执行程序服务器早已得到加载，则步骤403将变成多余的，且步骤303后的下一步骤将为步骤503。接下来，MIIDC服务器创建单个摄像机示例并将其连接至摄像机装置，并将输入装置控制示例连接至单个摄像机示例(步骤603)。最后，MIIDC服务器创建一接口，通过所述接口使第一客户端应用程序与所述单个摄像机示例进行通信(步骤703)。
图2中所描绘的摄像机示例106为一维持输入装置控制示例的状态的与摄像机装置的接口。输入装置示例106为一维持对已与摄像机装置建立的连接数量的必要计数及这些连接中每一个的特定状态的存储块。摄像机示例106还包含为对来自每一输入控制示例连接的请求进行优先权排序及对冲突的请求进行多路复用及解决所必需的逻辑。由于MIIDC服务器以一单独过程形式存在，因此必须为需要存取视频(及音频)数据的每一客户端复制所述视频(及音频)数据。为了减少数据复制，MIIDC服务器设计成记录视频(及音频)、检测运动、保存图片、以及一媒体源捕捉装置通常所具有的其它功能。因此，MIIDC服务器使数据复制仅限于那些需要直接存取媒体源(例如视频及音频)数据的应用。
例如，第一输入装置示例可能正在请求一分辨率为640×480像素的视频流，而第二及第三示例可能正在请求分辨率分别为320×480及160×120像素的视频流。在此种情形中，摄像机示例106随后将决定以640×480像素的更大分辨率来捕捉视频并随后将其按比例缩小或将其剪低至第二及第三示例所正请求的640×480像素的较低分辨率。在同一逻辑之后，如果随后第一视频示例与摄像机断开，则摄像机示例106随后将通过下述方式来满足来自第二及第三实例的分别请求320×280及160×120像素分辨率的请求以320×480像素的最高所请求分辨率捕捉视频以满足第二示例的请求，并随后将320×480像素的视频流按比例缩小或剪低至160×120像素以满足第三示例的请求。
在涉及三个输入装置控制示例的另一实例中，第一输入装置控制示例可向虚拟摄像机装置发送一运动检测命令，而其它两个示例只是在请求视频流。这时，摄像机示例106将以最高的所要求分辨率捕捉视频并只通过对第一输入装置控制示例的运动检测计算来传送该视频流。
在涉及三个输入装置控制示例的再一实例中，第二输入装置控制示例可能正在请求一对视频图像的文本覆盖，而另外两个示例只是在请求视频流捕捉。这时，摄像机106将以最高所要求的分辨率捕捉视频并只向流向第二输入装置请求的流添加所述文本覆盖。
虽然到现在为止所述的各实施例均是在一介接个人计算机主机的摄像机情况下来进行大体说明，但本发明的范围并非旨在仅限于摄像机或者甚至一特定类型的个人计算机主机。如上所述，本发明的各实施例涉及通过将一装置驱动文件虚拟化来使数个应用程序同时共享一输入装置，而将一装置驱动文件虚拟化又是通过将输入装置控制程序构建成一可执行程序服务器来实现的。虽然上述输入装置为一摄像机，但另一可配置成被同时共享的输入装置为麦克风。因此，输入装置示例(图2中的106)包含为将来自每一输入装置控制示例的请求按优先权排序及对冲突请求进行多路复用及解决所必需的逻辑。将视频源的共享能力扩展成还包括一音频输入源不仅是正常的，而且也几乎是强制性的，因为视频与音频最常见的是作为自然互补的媒体源捆绑在一起。
例如，重新参见图2，预计需要考虑在装置108正在记录视频的同时一麦克风(未显示)也在记录声音的情形。此时，例如，第一输入装置示例可能正在请求在44.1kHz下位深度为16位的音频，而第二示例可能正在请求在11.025kHz下位深度为8位的音频流。在此种情形中，输入装置示例将随后决定以最高采样速率及位深度捕捉音频并随后将其按比例缩小或压低至第二示例所请求的较低位深度或采样速率。
MIIDC及用以将一输入装置虚拟化的方法可构建于运行各种操作系统的许多计算平台上。一媒体源输入装置(例如一摄像机或一麦克风)通常介接一主计算机。所述主计算机最常为个人计算机，例如通常可使用的Mac计算机PC。然而，由于技术的进步正使计算装置与通信装置之间的界限变得模糊，因此本文所用的主计算机与一智能主机同义，且本文所用的智能主机是指包括任何具有一处理器、存储器、输入及输出构件、及存储构件的主机的其它实例。智能主机的其它实例-其也同样适于与本发明各实施例结合使用-包括手持式计算机、交互式机顶盒、薄的客户端计算装置、个人存取装置、个人数字助理及因特网设备。
本发明的其它方面涉及使一应用程序能够与所述输入装置服务器可执行程序进行通信的客户端侧机构。如上所述，所述MIIDC可执行程序构建于一其中每一应用程序均为一客户端的客户端-服务器架构下。因此，客户端必须能够与服务器进行通信。本发明的方法提供数种使一应用程序能够与所述MIIDC服务器进行通信的机构。在一PC/Windows环境中，一第一客户端侧机构通过一称作输入装置门户的ActiveX控制来传送。一同样处于一PC/Windows环境下的第二客户端侧机构则通过一DirectShow视频捕捉源滤波器来传送。
根据所述门户方法的所述客户端侧机构包括与所述MIIDC服务器进行通信并向一应用程序提供用户接口元件。根据所述门户方法，用以将一输入装置虚拟化的所有功能均由所述MIIDC服务器实施，且因此与所述MIIDC服务器进行通信的应用程序将需要进行用户接口编程。为实现此目的，根据所述视频门户方法，提供一模板以使不同的应用程序提供商能够产生其自己的定制的输入装置门户。
根据所述第二种方法(即DirectShow方法)的客户端侧机构利用称作滤波器的标准化DirectShow模块组件。由MicrosoftTM提供的DirectShowTM服务能为多媒体流提供回放服务，包括从装置中捕捉多媒体流。DirectShowTM服务的核心是一由称作滤波器的可插式组件构成的模块系统。
这些模块组件可分为源、转换及再现。滤波器通过将数据读取、复制、修改或写入至一文件中或将所述文件再现至一输出装置上来处理数据流。所述滤波器具有输入及输出构件并彼此连接成一称作滤波器图的结构。应用程序使用一称作滤波器图管理器的目标程序来汇编所述滤波器图并通过其来移动数据。滤波器图管理器处理从一输入装置到所述回放装置的数据流。可通过参看所属领域的技术人员所知的适当文档来获得对DirectShowTM服务及MicrosoftTMDirectXTM媒体软件开发工具包的进一步说明。
此第二客户端侧机构用一直接与所述MIIDC服务器进行通信的虚拟源滤波器替换标准源(媒体输入)滤波器。所述虚拟源滤波器对于所述MIIDC服务器而言为一客户端。借助此机构，使一DirectShow应用程序无法区分“实际的”与“虚拟”的源滤波器。此第二种客户端侧机构的优点在于所编写的用于在一DirectShow环境中起作用的任何应用程序均将能够很容易地共享一输入装置，而无需进行任何额外的用户接口编程即能够与所述MIIDC服务器进行通信。
图4为一图解说明一其中可向一个或多个应用程序提供来自一个或多个源的视频及其它媒体数据的本发明实施例的方块图。所述方块图包括媒体源410、媒体数据客户端应用程序430及一虚拟源420。
有数个源410a、410b、...，410m可提供多媒体数据。这些数据源可为可捕捉某些类型的多媒体数据(例如视频及/或静止图像)的数据捕捉装置。多媒体数据源410的实例包括外围装置，例如麦克风、独立摄像机、网络摄像机、数字照相机、及/或其它视频/音频捕捉装置。在一实施例中，某些源410是由Logitech公司(Fremont，CA)提供的QuickCam网络摄像机。所述数据可通过一设置于标准或定制的计算机上的BluetoothTM/IR接收机、无线USB、或各种输入/输出接口在一无线连接上提供。所述数据流可发送至一数据槽，例如一文件、扬声器、客户端应用程序或装置。
有数个客户端应用程序430a、430b，...，430n需要使用源410所提供的数据。客户端应用程序430可为任一对源430而言为客户端的用户。在一实施例中，一些客户端应用程序430为Instant Messager(IM)。当前可使用的IM程序的一些实例为Microsoft公司(Redmond，WA)的MSNMessenger、由American Online公司(Dulles，VA)提供的American Online Instant Messenger(AIM)及由Yahoo！公司(Sunnyvale，CA)提供的Yahoo！Instant Messager。在另一实施例中，一些客户端应用程序430为Video Conferencing(视频会议)应用程序，例如由Microsoft公司(Redmond，WA)提供的NetMeeting。在一实施例中，一些客户端应用程序430为例如由Microsoft公司(Redmond，WA)提供的Windows Media Player等回放/记录应用程序、例如由Microsoft公司(Redmond，WA)提供的Windows Messenger等通信应用程序、视频编辑应用程序、或任何其它类型的通用或专用多媒体应用程序。
虚拟源420连接至源410并自其请求数据。然后，虚拟源420根据需要对此数据进行处理、复制及格式化，然后向客户端应用程序430提供一个流。
在一实施例中，虚拟源420创建于所述源410所附接到的且上面驻存有客户端应用程序430的主机(例如一计算机系统)上。在一实施例中，虚拟源420创建于核心模式中。在一实施例中，虚拟源420使源410能够对客户端应用程序430完全透明。源410对客户端应用程序430完全隐藏，且因此客户端应用程序430完全不知晓源410的存在。客户端应用程序对所需媒体装置(摄像机等)的调用基本上被选路至本发明的虚拟装置-其在系统总线上自行登记为所需装置。一WDM总线枚举器附接至根总线。因此，此枚举器自身在引导时(或在安装时)与所有其它根枚举装置一起由操作系统进行枚举。此枚举器负责管理一虚拟装置总线。为此，其监控将要虚拟化的实体装置的到达与离开并为其发现的每一实体装置枚举一虚拟装置。
换句话说，一客户端应用程序430无法分辨其正在与除一正常源外的任何事物进行通信。此外，用户也无法分辨他/她正在与一拟虚源420交互作用。根据本发明的一实施例，为使用一系统，用户不需要选择任何替代虚拟装置。更确切地说，用户的体验是完全无缝且透明的。
在一实施例中，客户端应用程序430仍然完全不知道来自数据源410的数据流的原始格式/内容。因此，一根据本发明一实施例的系统可接收各种各样的格式及内容。在一实施例中，基本源410不支持客户端应用程序430所请求的帧速率及/或格式。本发明的视频驱动器发送控制信号来选择实体摄像机的所需格式及其它可控制特征。例如，可设定任一客户端正在请求的最高分辨率及帧速率，以使虚拟驱动器可为其他请求那些不同值的客户端产生较低的帧速率及分辨率。其它参数可因客户端而异，例如电子聚焦、扫视及俯仰。
所述数据流可呈各种格式中的任何一种。例如，视频流可经过压缩或解压缩，并呈各种格式中的任何一种，包括RGB、YUV、MJPEG、各种MPEG格式(例如MPEG1、MPEG2、MPEG4、MPEG7等等)、WMF(WindowsMedia Format)、RM(Real Media)、Quicktime、Shockwave及其它格式。最后，所述数据还可呈AVI(音频视频交错)格式。
在一实施例中，虚拟源420评定并确定用以自源410获得数据的最适当格式以便将所述数据提供至客户端应用程序430。在一实施例中，各客户端应用程序430请求不同的格式及/或帧速率，且虚拟源420可满足每一客户端应用程序430的请求。在一实施例中，将来自不同的源410的多个视频流组合成一个来自虚拟源420的虚拟流，然后可由一个或多个客户端应用程序430存取所述虚拟流，其中每一客户端均可能请求一不同的格式及帧速率。
在本发明的一些实施例中，该实施方案将仅适用于特定源而不适用于其它源。例如，一根据本发明一实施例的实施方案可仅适用于来自一特定提供商的网络摄像机而不适用于来自其它提供商的网络摄像机。在一实施例中，对所述源(要虚拟化的装置)使用加密的信号交换，以便通过此种方式只可使用某些源。
在一实施例中，可向一应用程序提供多个视频源，所述应用程序将并排显示这些视频源或将其显示于单独的观察窗口中。例如，在保安应用中可通过一由所显示的不同摄像机图像组成的组合画面来对多个摄像机进行监控。或者，可使用单个摄像机的两个图像传感器来捕捉基本相同的景物。其中一个图像传感器可为一用于视频或运动检测的低分辨率传感器，而另一传感器可为一用于静止图像的高分辨率传感器。或者，可使用一摄像机中取自不同位置的图像或取自多个摄像机的图像来构造一3维(3D)图像或视频。所述3D图像可构造于驱动器中，或构造于客户端应用程序中。在另一实施例中，可使图像在驱动器或客户端应用程序中彼此叠加。这样做可能是为了例如在一个人背后放置不同的背景。
所属技术领域：
的技术人员将理解，本发明也可实施为其它具体形式，此并不背离其基本特征。例如，在本发明的各实施例中，并非处理视频及音频数据，而是可处理静止图像数据，或除处理视频及音频数据以外，还可处理静止图像数据。这些其它实施例也打算包括于在随附权利要求
书中所规定的本发明范围内。
权利要求
1.一种用于透明地向复数个客户端应用程序提供多媒体数据的系统，所述系统包括一提供所述多媒体数据的数据源；一使用所述多媒体数据的第一客户端应用程序；一使用所述多媒体数据的第二客户端应用程序；一以通信方式耦合至所述数据源及所述第一及第二客户端应用程序的虚拟数据源，其中所述虚拟源从所述数据源获得所述多媒体数据，并将所述多媒体数据提供至所述第一客户端应用程序及所述第二客户端应用程序。
2.如权利要求
1所述的系统，其中所述多媒体数据为视频数据。
3.如权利要求
2所述的系统，其中所述数据源为一网络摄像机。
4.如权利要求
1所述的系统，其中所述第一客户端应用程序为一即时消息接发应用程序。
5.如权利要求
1所述的系统，其中所述虚拟源位于核心模式中。
6.如权利要求
1所述的系统，其进一步包括一以通信方式耦合至所述虚拟源的第二数据源，其中所述第一客户端应用程序接收一将来自所述第一数据源与所述第二数据源的数据相组合的单个数据流。
7.如权利要求
1所述的系统，其中所述第一客户端应用程序请求一不同于由所述数据源提供的数据格式的数据格式。
8.如权利要求
7所述的系统，其中所述虚拟源确定要自所述数据源接收的所述数据的所述格式以便能够有效地创建所述客户端应用程序所请求的所述数据的所述格式。
9.如权利要求
1所述的系统，其中所述第一客户端应用程序请求一不同于所述数据源所提供的数据的帧速率的数据帧速率。
10.一种用于透明地将多媒体数据自复数个数据源提供至一客户端应用程序的系统，所述系统包括一提供第一多媒体数据的第一数据源；一提供第二多媒体数据的第二数据源；一以通信方式耦合至所述第一数据源及所述第二数据源并耦合至所述客户端应用程序的虚拟数据源，其中所述虚拟源获得来自所述第一数据源的所述第一多媒体数据及来自所述第二数据源的所述第二多媒体数据，并向所述客户端应用程序提供一将所述第一多媒体数据与所述第二多媒体数据相组合的单个数据流。
11.一种用于向复数个客户端应用程序提供多媒体数据的方法，其中所述多媒体数据由一数据源提供，其中处理对所述复数个客户端应用程序是透明的，所述方法包括通过一虚拟源来获得由所述数据源提供的所述数据；修改所述数据的帧速率或格式中的一者；及将所述经修改的多媒体数据提供至所述复数个客户端应用程序中的每一个。
12.如权利要求
11所述的方法，其中所述多媒体数据为视频数据。
13.如权利要求
11所述的方法，其中所述多媒体数据为静止图像数据。
14.一种用于透明地将多媒体数据自复数个数据源提供至一客户端应用程序的方法，所述方法包括通过一虚拟源自第一数据源获得第一多媒体数据；通过所述虚拟源自第二数据源获得第二多媒体数据；组合所述第一多媒体数据与所述第二多媒体数据以创建一单个数据流；及将所述单个数据流提供至所述客户端应用程序。
15.如权利要求
14所述的方法，其中所述第一多媒体数据为一来自一摄像机中一第一图像传感器的第一视频图像且所述第二多媒体数据为一来自所述摄像机中一第二图像传感器的第二视频图像。
16.如权利要求
15所述的方法，其中所述第一视频图像为低分辨率且所述第二视频图像为高分辨率。
17.如权利要求
14所述的方法，其进一步包括自所述第一及第二视频图像创建一三维图像。
18.一种包括一用于促成对一输入装置的同时共享的计算机程序的计算机可用媒体，所述程序包括，调用代码，其用于响应于一自一第一应用程序接收到的请求存取所述单个输入装置的第一存取请求来调用一输入装置控制程序；关联代码，其用于在根据所述输入装置控制程序创建所述单个输入装置示例后即刻使一单个输入装置示例与所述单个输入装置相关联；产生代码，其用于响应于所述第一请求而产生一第一控制示例，所述第一控制示例与所述第一应用程序相关联；关联代码，其用于将所述第一控制示例与所述单个输入装置示例相关联，以便所述第一应用程序可使用所述第一控制示例与所述单个输入装置示例之间的所述关联来存取所述单个输入装置；产生代码，其用于响应于一自一第二应用程序接收到的请求存取所述单个输入装置的第二存取请求来产生一第二控制示例；及关联代码，其用于使所述第二控制示例与所述单个输入装置示例相关联，以便所述第二应用程序可使用所述第二控制示例与所述单个输入装置示例之间的所述关联来存取所述单个输入装置。
专利摘要
本发明使单个媒体流能够以一种对客户端/应用程序完全透明的方式无缝地暴露至所期望多的客户端/应用程序。此外，本发明的一实施例将来自多个装置(例如网络摄像机、麦克风、等等)的媒体流组合成一单个虚拟流，随后可由所期望多的客户端存取所述单个虚拟流。在本发明的一些实施例中，每一客户端均可请求一不同的格式及帧速率。此外，在本发明的一些实施例中，将来自一个或多个源的媒体数据提供给一个或多个客户端应用程序的能力对所述应用程序以及用户完全透明。
文档编号H04N7/173GK1992619SQ200610152466
公开日2007年7月4日 申请日期2006年9月29日
发明者阿诺·格拉特龙, 阿龙·斯坦里奇, 蒂姆·迪克曼 申请人:罗技欧洲公司导出引文BiBTeX, EndNote, RefMan