专利名称：多例输入设备控制的利记博彩app
技术领域：
本发明涉及摄像机，更具体地说，涉及摄像机与应用程序的接口。
以往，当一个应用程序连接到一部摄像机时，其他的程序将被禁止使用这部摄像机。当一个应用程序试图和一部摄像机通信时，它将调用相应的驱动程序文件或动态连接库(DLL，*.dll)文件。通常，一个动态连接库提供一个或多个特殊的函数，一个应用程序通过和该动态连接库(DLL)建立连接来访问这些函数。动态连接库也可以同时包括数据。一些动态连接库也提供有操作系统(如视窗操作系统)，它们可以用于任何操作系统应用程序。其它的动态连接库专门为特殊的应用程序编写，他们和应用程序一起被调入系统(如一个视频控制应用程序)，当一个视频控制应用程序请求连接到一部摄像机时，相应的驱动程序便检查以确保没有其它的应用程序已经打开了该驱动程序文件(*.dll)，如果没有，该驱动程序将打开相应的驱动程序文件。当打开后，通过这个打开的摄像机驱动程序文件，这里便存在了一个在摄像机和相应的应用程序之间的单线程的连接。如
图1所示。
如图1中所描述的，驱动程序文件14被驱动程序12打开，驱动程序12被调用应用程序10调用，同时，驱动程序文件14被载入调用应用程序的存储器空间中。由于摄像机驱动程序文件14已经被该应用程序10打开，下一个企图访问该摄像机的应用程序将被禁止访问。这是因为摄像机驱动程序文件已经被调入了第一个应用程序的存储器中，将无法被其它的调用应用程序访问。因此，每一个可能调用一个摄像机的应用程序必须考虑该摄像机已经被其它的应用程序使用的可能性。所以，这样的应用程序将被阻断，因为需要首先检查确定是否其它的首先被执行的应用程序已经连接到了该摄像机，如果其它的首先被执行的应用程序已经连接到了该摄像机，第2个调用应用程序必须有允许它和已经连接到摄像机的应用程序商议摄像机共享的例程。但是，这种共享是单实例的，这意味着在摄像机和第2个应用程序的连接可以被建立之前，摄像机和第1个应用程序之间的连接将不得不被中断(即，第1个应用程序将不得不被终止或者摄像机被关闭)。所有权，优先权，其它相关的安全问题以及适当的错误处理必须通过两个竞争的应用程序间的通信来解决。目前，甚至没用应用程序试图去解决上述任意一个问题，因此，如果一个调用应用程序和摄像机之间的连接不能被建立，异常的应用程序错误被操作系统解决，操作系统发送更加不清楚、不可理解的错误消息，使得最终的用户仅仅被通知一个正确的连接无法被建立。
应用程序的大小，适用性和可用性在一直不断地增加，应用程序的发展趋势也已经由向单一的巨大的应用程序发展转变为向由许多小子程序组成的应用程序发展。这种模块化的方法集中了许多优点，如使后续的调整和配置变得很容易。此外，操作系统的供应商同样已经采用了这样的模块化的方法，并提供了许多标准的子程序和对象来处理应用类的功能。如队列化文件到打印机中，载入并运行打印机动态连接库文件来打印文件。这些动态连接库文件本身也是对象或子程序。为了使由不同的高级语言编写的对象和小子程序之间允许相互操作，操作系统的供应商已经开发了可执行程序的模型，这些模型可以在二进制级别上相互兼容。微软公司开发的组件对象模型(COM)便是这样一个二进制码模型。COM使程序员可以开发可以被任何和COM兼容的应用程序访问的对象。尽管将大的单一的应用程序转化为一组小的子程序和对象可以获得很多好处，但这些好处必须和由于需要额外的程序支持这样的子程序和对象之间的进程通信而增加的负担相平衡。
除了在实用性和复杂性上的发展，多元的应用程序正在从单一主机上移植到多主机的异构网络环境中。因此，我们也已经听说了这样的单独的应用程序，它由许多由不同高级语言编写的子程序组成，其中每一个子程序位于一台分立的计算机上，而所有这些计算机通过一个网络被连接到一起。在这样的实现中，对高效的网内的和网间的和进程间的通信需求成为了一个新的问题，从程序员编写应用程序的主要任务中分离出来。程序员不得不处理由于将应用程序组件分布到网络中带来的通信问题。再一次，操作系统的供应商们已经意识到了这个挑战和这种潜在的转移，并且以不同的方式致力于它的解决。微软公司已经通过开发分布式组件对象模型(DCOM)扩展了COM的功能。DCOM是COM的一个扩展，用来支持通过网络的对象的分布。除了作为COM的一个扩展，DCOM提供了一个接口用来处理网络通信的细节问题，以便使开发人员将精力集中于他们的主要工作——专用应用程序的开发上，DCOM被设计用来满足企业对分布组件结构的需求。例如，一家公司可能希望建造并采用一个客户订单登记程序，该程序涉及几种不同的功能，如税务计算，客户信用卡核实，货物清单管理，保证说明更新，和订单登记。使用DCOM，该应用程序可以由5个分立的组件建立，运行于一个服务器上，可以通过浏览器进行访问。该程序中的位于不同计算机上的每一个组件访问一个不同的数据库。程序员可以专心于应用程序的开发，而DCOM来处理关于该应用程序的分立组件之间的进程间通信方面的问题。例如，DCOM将处理组件通信和合适的队列的集成，以及在一台服务器上的组件应用程序和基于超文本链接语言(HTML)的因特网应用程序的结合。
本发明结合了一个可执行程序的特性和对多个应用程序共享单一的输入设备(如摄像机)的需要。一个输入设备如摄像机是一个外部设备，它在响应一个来自应用程序的调用时被打开并一直保持打开状态。本发明提供了一个可执行程序，它被实现为一个允许多个应用程序和单一的输入设备通信的进程。通过建立一个虚拟的通向物理输入设备的接口(一个实例)，和将该输入设备控制可执行文件载入一个进程中，上述的发明可以被实现。一个实例是一个实际的使用和因此导致的调入存储器的实体的一份拷贝的虚拟建立。该可执行程序进程作为一个服务器，允许多个应用程序和相同的输入设备实现接口。该多例输入设备控制(MIIDC)可执行程序响应每一个应用程序的请求，就好像输入设备正在为该调用应用程序打开一样。这样每一个应用程序就可以和该输入设备实例进行通信。而不必中断其它正在和同样的输入设备进行通信的应用程序。
在一个实现中，这个(MIIDC)可执行程序可以是一个DCOM对象。DCOM也可以作为一个允许多个应用程序和单一的输入设备进行通信的接口。这个DCOM接口处理所有的接口操作，例如载入，执行缓冲，卸载以及调用该可执行程序。在基于DCOM的实现中，这个MIIDC对象本身就是一个DCOM服务器，该MIIDC程序在一个体现为可执行服务器的DCOM对象中，通过连接到一个输入设备开始工作。随后，该MIIDC变成了一个体现为可执行程序的DCOM对象，这意味着该MIIDC是一个进程——像任何其他的操作系统(O/S)进程一样——可以被许多应用程序共享。通过将一个输入设备访问程序放入到一个分立的可执行进程中，这个输入设备便可以被多个应用程序所共享。在应用程序看来，这个DCOM接口好像正在仅仅为调用该DCOM对象的应用程序打开，但这时，这里只有一个输入设备的实例。
MIIDC被实现以便于对于每一个实际的输入设备，DCOM服务器建立单一的输入设备实例并且连接到该输入设备。当一个应用程序和输入设备控件一一这是一个可执行的DCOM服务器——连接后，该DCOM服务器建立一个MIIDC实例(和一个接口)，通过它，该应用程序可以和这个单一输入设备实例通信。这个单一输入设备实例为每一个输入设备控制实例提供数据输出，这样便允许多个应用程序同时和一个输入设备通信。全局的设置是专用的(MIIDC)实例。此外，该输入设备实例被保护以便使该输入设备控制程序的多个实例不会执行干扰其他实例处理数据的任务。使用这种新的方法，应用程序可以被编写，而不用考虑其他应用程序已经使用同样输入设备的可能性。
为了进一步了解本发明的本质和优点，下面将结合附图进行详细的描述。
图1是显示用于一个应用程序和一个摄像机设备通信的现有技术方法的方框图。
图2是描述本多例输入设备控制程序的一个实施例的方框图。
图3是关于一个应用程序和一个输入设备的连接步骤的流程图。
图2所示的方框图显示了本多例输入设备控制程序(MIIDC)的一个实施例。在这个实施例中，输入设备是一个摄像机，可执行程序是一个DCOM可执行服务器。本图显示了多个应用程序如何共享单一的摄像机。一旦第一个应用程序100呼叫连接摄像机108，这个呼叫就被传送到应用程序接口(API)102。微软公司提供的相关文件和网站可以用来参考以获得更多关于DCOM的详细说明。该DCOM API处理DCOM可执行程序的调入并且建立一个从应用程序到DCOM可执行程序200的连接。该DCOM服务器200建立单一的摄像机实例106和第一个MIIDC实例104，接着，该DCOM服务器200将这个单一的摄像机实例106连接到相应摄像机的驱动程序107，将该摄像机驱动程序107连接到摄像机设备108，并同时将第一个MIIDC实例104连接到这个单一的摄像机实例106。该摄像机实例是一个通向摄像机设备108的虚拟接口。一个实例是一个实际的使用和调入存储器的实体的一份拷贝的虚拟建立。在这个实例中，所有的实例的存储器在该可执行服务器中分配。最终，连接300被建立，允许客户程序100和摄像机设备108通过这个新实例化的DCOM接口(单一摄像机实例)进行交互。
一旦第二个应用程序11O呼叫连接到该摄像机108，该DCOM服务器200就建立第二个MIIDC实例114，并将它连接到这个单一摄像机实例106以允许第二个客户应用程序110和该摄像机设备108通过这个单一的摄像机实例106进行交互，该交互通过第二个建立的连接31O。以此类推，随后的应用程序120将通过该DCOM实例化的接口106用随后建立的连接320和该摄像机设备进行交互。
图3所示的流程图显示了图2所示的过程，一旦一个客户应用程序呼叫连接到该摄像机设备(步骤103)，该应用程序的呼叫被送到该DCOM API(步骤203)，然后，该DCOM API确定是否由DOCM实现的MIIDC可执行程序已被载入，一般地说，第一个客户应用程序使该MIIDC可执行程序被载入。如果该MIIDC可执行服务器没有被载入，该DCOM API接受这个呼叫并使该DCOM服务器载入这个基于DCOM实现的MIIDC可执行服务器(步骤403)。随后，该MIIDC服务器建立一个输入设备控制实例(步骤503)。如果该MIIDC可执行服务器已经被载入，那么步骤403就没有必要了，步骤503将跟在步骤303之后。该MIIDC服务器接着建立单一的摄像机实例并且将该实例连接到该摄像机设备，将该输入设备控制实例连接到该单一的摄像机实例(步骤603)，最后，该MIIDC服务器建立一个接口，通过这接口，第一个客户应用程序和这个单一的摄像机实例进行通信(步骤703)。
图2所示的摄像机实例106是一个和该摄像机设备108的接口，用来维护该输入设备控制实例的状态。该输入设备实例106是这样一块存储器，它维护着有关已经和该摄像机设备建立的连接的数目的必要统计，和这样的每一个连接的特定状态。该摄像机设备同时集成了必要的逻辑，以确定来自每一个输入设备控制实例连接的请求的优先级，合并请求，和处理请求冲突。
例如，第一个输入设备实例可能要求具有640*480像素分辨率的射频数据流，而第二个和第三个实例可能分别要求分辨率是320*480像素和160*120像素的射频数据流。在这种情况下，这个摄影机实例将以最高的640*480像素的分辨率采集图像，然后再将分辨率分别降低到第二个实例和第三个实例要求的分辨率。遵循同样的逻辑，如果后来第一个视频实例和摄影机断开连接，这个摄影机实例106将分析分别来自第二个实例的分辨率是320*480像素的请求和来自第三个实例的分辨率是160*120像素的请求，然后以最高的分辨率320*480像素采集图像以满足第二个实例的要求，然后在将射频数据流的分辨率由320*480降低到160*120以满足第三个实例的要求。
在另一个涉及三个输入设备控制的实例中，第一个输入设备控制实例可能向该虚拟摄像机设备发送一个移动检测命令，而其他的两个实例仅仅要求射频数据流。这时，该摄像机实例106将以被要求的最高分辨率采集图像，并向第一个输入设备控制实例发送通过移动检测计算的射频数据流。
在同样一个涉及三个输入设备控制的实例中，第二个输入设备控制实例可能要求在视频图像上覆盖一段文本，而其他两个实例则仅仅要求采集射频数据流。现在，该摄像机实例106将以最高的分辨率采集图像，并且仅仅在流向第二个输入设备请求的射频数据流中添加文本覆盖。
本发明同样可以在不背离本质特征的情况下以其它的特殊的形式实施。例如，该MIIDC可以被实现为任何其它的可执行进程，而不是一个基于DCOM的进程；任何其他的接口协议而不是DCOM接口可以被用来允许多个应用程序和那个进程进行通信。这些其他的实施例将被包括在本发明的范围之中，这个范围将在下面的权利要求中确定。
权利要求
1．一个允许多个客户应用程序同时和单一的输入设备进行通信的输入设备控制程序，其中，所说的输入设备控制程序被作为一个进程载入，所有后续的应用程序呼叫该进程以和所说的这个单一的输入设备建立通信。
2．按照权利要求1中所说的输入设备控制程序，其中所说的输入设备控制程序包括实现以下功能的子程序a)视频控制方法，包括ⅰ)初始化一个视频控制；ⅱ)采集静态数字图像；ⅲ)记录数字视频图像；ⅳ)获取视频驱动程序的信息；ⅴ)设置摄像机属性；ⅵ)获取摄像机属性；b)摄像机事件通知，包括ⅰ)移动检测通知；ⅱ)可视音频(AVT)错误通知；ⅲ)摄像机分离通知；ⅳ)摄像机重新连接通知。
3．按照权利要求1中所说的输入设备控制程序，其中所说的用于处理所有通信协议细节过程包括a)载入上述的输入设备控制程序；b)用相关的输入/输出数据调用上述的输入设备控制程序；c)缓冲从上述的输入设备控制程序输出的和向该程序输入的数据；d)执行上述的输入设备控制程序；e)卸载上述的输入设备控制程序。
4．一个允许多个客户应用程序同时和单一的输入设备进行通信的输入设备控制程序，其中所说的输入设备控制程序响应于要求与上述的输入设备建立第一个连接的第一个应用程序ⅰ)传送上述的第一个应用程序的呼叫到一个进程的应用程序接口(API)；ⅱ)使上述的进程的网络协议将上述可执行的输入设备控制程序载入到一个进程服务器中；ⅲ)使上述的进程服务器建立单一的输入设备实例并连接这个单一的输入设备实例到上述的输入设备；ⅳ)使上述的进程服务器建立第一个输入设备控制实例并且连接该第一个输入设备控制实例到上述的单一的输入设备实例；ⅴ)使上述的进程服务器建立一个接口，通过它，上述的客户应用程序和上述的单一的输入设备实例进行通信；ⅵ)响应来自第二个应用程序的要求与上述的单一的输入设备实例建立第二个连接的呼叫，建立第二个输入设备控制实例，并连接上述的第二个输入设备控制实例到上述的单一的输入设备实例以允许上述的第二个应用程序和上述的同一个单一的输入设备实例进行通信。
5．按照权利要求4中所说的输入设备程序，其中所说的输入设备控制程序是一个分布组件对象模型(DCOM)可执行程序，包括实现以下功能的子程序a)视频控制方法包括ⅰ)初始化一个视频控制；ⅱ)采集静态数字图像；ⅲ)记录数字视频图像；ⅳ)获取视频驱动程序的信息；ⅴ)设置摄像机属性；和ⅵ)获取摄像机属性；b)摄像机事件通知包括ⅰ)移动检测通知；ⅱ)可视音频(AVT)错误通知；ⅲ)摄像机分离通知；和ⅳ)摄像机重新连接通知。
6．按照权利要求4中所说的输入设备控制程序，其中所说的进程是一个分布组件对象模型(DCOM)可执行程序。
7．一个允许多个客户应用程序同时和单一的输入设备进行通信的分布组件对象模型(DCOM)可执行输入设备控制程序，其中所说的程序响应于要求与上述的输入设备建立第一个连接的第一个应用程序ⅰ)传送上述的第一个应用程序的呼叫到一个DCOM应用程序接口(API)；ⅱ)使上述的DCOM网络协议将上述可执行的输入设备控制程序载入到一个DCOM服务器中；ⅲ)使上述的DCOM服务器建立单一的输入设备实例并连接这个单一的输入设备实例到上述的输入设备；ⅳ)使上述的DCOM服务器建立第一个输入设备控制实例并且连接这个第一个输入设备控制实例到上述的单一的输入设备实例；ⅴ)使上述的DCOM服务器建立一个接口，通过它，上述的客户应用程序和上述的单一的输入设备实例进行通信；ⅵ)响应来自第二个应用程序的要求与上述的单一的输入设备实例建立第二个连接的呼叫，建立第二个输入设备控制实例，并连接上述的第二个输入设备控制实例到上述的单一的输入设备实例以允许上述的第二个应用程序和上述的同一个单一的输入设备实例进行通信。
8．一种实现多个客户应用程序和单一的输入设备进行通信的方法，该方法包括ⅰ)传送第一个应用程序的呼叫到一个进程的应用程序接口(API)；ⅱ)使上述的进程的网络协议将上述可执行的输入设备控制程序载入到一个进程服务器中；ⅲ)使上述的进程服务器建立单一的输入设备实例并连接这个单一的输入设备实例到上述的输入设备；ⅳ)使上述的进程服务器建立第一个输入设备控制实例并且连接该第一个输入设备控制实例到上述的单一的输入设备实例；ⅴ)使上述的进程服务器建立一个接口，通过它，上述的客户应用程序和上述的单一的输入设备实例进行通信；ⅵ)响应来自第二个应用程序的要求与上述的单一的输入设备实例建立第二个连接的呼叫，建立第二个输入设备控制实例，并连接上述的第二个输入设备控制实例到上述的单一的输入设备实例以允许上述的第二个应用程序和上述的同一个单一的输入设备实例进行通信。
9．按照权利要求8中的方法，其中所说的可执行输入设备控制程序是一个分布组件对象模型(DCOM)可执行程序。
10．按照权利要求8中的方法，其中所说进程是一个DCOM进程。
全文摘要
一个可执行的应用程序,该程序实现为一个允许多个应用程序和一个单一的输入设备进行通信的进程。上述这些通过将该输入设备控制程序作为一个进程载入存储器来实现。因此这个可执行程序是一个允许多个应用程序和同一个输入设备接口的服务器。该多例输入设备控制可执行程序响应任何一应用程序的请求,如同输入设备正在为该调用应用程序打开一样。每个应用程序可以和该输入设备实例通信,而不会中断其它正在和同一输入设备通信的应用程序。
文档编号G06F13/12GK1312503SQ0012069
公开日2001年9月12日 申请日期2000年11月10日 优先权日1999年11月10日
发明者蒂莫西·D·迪克曼, 阿龙·D·斯坦立奇 申请人:罗技电子股份有限公司