專利名稱:從不同源向不同客戶端應用提供多媒體數(shù)據(jù)的方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及媒體源輸入裝置，例如麥克風及攝像機，且具體而言涉及媒體源輸入裝置與應用程序的接口連接。
背景技術：
傳統(tǒng)上，當一個應用程序連接至一媒體源時，所有其它應用程序均被禁止使用該媒體源。在一常見的個人算計機情況下，當一應用程序請求與一媒體源進行通信時，所述應用程序會調(diào)用驅(qū)動文件或動態(tài)鏈接庫(DLL或*.dll)文件。通常，一DLL提供一個或多個特定功能且一程序通過創(chuàng)建一通至所述DLL的鏈接來存取所述功能。DLL也可包含數(shù)據(jù)。一些DLL配備有操作系統(tǒng)(例如Windows操作系統(tǒng))并可供用于任一操作系統(tǒng)應用程序。其它DLL是針對一特定應用程序得到寫入并加載有所述應用程序(例如一媒體源控制應用程序)。當一媒體源控制應用程序請求連接至一媒體源時，驅(qū)動器會進行檢查以確認沒有其它應用程序已打開所述特定攝像機驅(qū)動文件(*.dll)，且若沒有其它應用程序已打開，則驅(qū)動器將打開所述特定驅(qū)動文件。如此一來，此時便通過所打開的媒體源(例如攝像機)驅(qū)動文件在媒體源(例如攝像機)與應用程序之間存在一如圖1中所見的單線程連接。
圖1顯示一與一媒體源連接的應用程序，所述媒體源為一攝像機。如圖1中所描繪，驅(qū)動文件14是通過由發(fā)出調(diào)用的應用程序10所調(diào)用的驅(qū)動器12來打開并加載于發(fā)出調(diào)用的應用程序的存儲器中。由于攝像機驅(qū)動文件14已被應用程序10打開，因此禁止下一試圖調(diào)用攝像機的應用程序打開攝像機驅(qū)動文件14。與在多個應用程序之間共享一媒體源時發(fā)生的沖突相關的問題稱作應急問題。由于典型的輸入裝置驅(qū)動器在任何給定時刻只允許一個應用程序使用輸入裝置數(shù)據(jù)，因此會存在應急問題。這是因為攝像機驅(qū)動文件已加載于第一應用程序的存儲器中且無法供另一發(fā)出調(diào)用的程序存取。因此，每一可能會調(diào)用一攝像機的應用程序均必須慮及可能已在使用所述攝像機的另一應用程序的存在。因此，此種應用程序受制于下述需要需要首先進行檢查以判定是否執(zhí)行了已連接至所述攝像機的另一第一應用程序，且若如此，則第二發(fā)出調(diào)用的程序必須具有允許其協(xié)商對所述攝像機的共享的例程。然而，此種共享為一單一瞬時共享，此意味著在能夠建立攝像機與第二應用程序之間的連接之前將須中斷(即第一應用程序?qū)㈨氷P閉或攝像機將須斷開)攝像機與第一應用程序之間的連接。還必須通過這兩個競爭的應用程序之間的通信來解決權(quán)限、優(yōu)先權(quán)及其它安全方面以及適當?shù)腻e誤處理。目前，還沒有哪一應用程序甚至嘗試著解決這些問題中的任何一個，且因此，如果不能在一發(fā)出調(diào)用的程序與一攝像機之間建立連接，則由操作系統(tǒng)通過發(fā)出相當粗糙且難以辨認的錯誤消息來解決意外應用程序錯誤，此使最終用戶只能推斷出不能建立一適當?shù)倪B接。充其量，第二發(fā)出調(diào)用的應用程序會接收到一指示所調(diào)用的裝置當前正在使用中且不可用的消息。
應用程序的大小、靈活性及可用性一直在不斷增大，且目前的趨勢是從大的單塊式應用程序發(fā)展到由許多更小的子程序構(gòu)成的程序。此種積木式方法提供許多優(yōu)點，例如易于以后的修改及可配置性。而且，操作系統(tǒng)提供商(例如Microsoft)也已采用此種模塊式方法且因此提供許多標準的子程序或目標程序，這些子程序或目標程序處理許多實用型功能，例如將發(fā)送至打印機的文件排隊及加載并運行打印機驅(qū)動器(例如DLL)文件以打印文件。所述驅(qū)動(例如DLL)文件本身為目標程序或子程序。此外，為努力實現(xiàn)目標程序與以不同的高級編程語言編寫的較小子程序之間的互操作性，操作系統(tǒng)提供商已開發(fā)出可在二進制層次上彼此兼容的可執(zhí)行程序模型。由Microsoft公司開發(fā)出的一種這樣的二進制碼模型為組件對象模型(COM)。COM使程序師能夠開發(fā)出可由任何適應于COM的應用程序存取的目標程序。雖然可通過從大的單塊式應用程序轉(zhuǎn)換成較小子程序及目標程序的集合來實現(xiàn)許多優(yōu)點，但這些優(yōu)點必須與因需要附加例程來允許在這些子程序及目標程序之間進行過程間通信而施加的負荷保持平衡。
除復雜性及可用性增大外，多單元應用程序還一直在從單主機站點往多主機多機種網(wǎng)絡環(huán)境變遷。所以，目前由許多分別以不同的高級編程語言編寫并分別駐存于一單獨計算機上的不同例程構(gòu)成的單個應用程序并不陌生，其中所有這些計算機均通過網(wǎng)絡彼此連接。在此類實施方式中，對于有效的網(wǎng)絡內(nèi)及網(wǎng)路間及過程間通信的需求可自然而然地形成，從而不利于程序師的編寫應用程序的主要任務。程序師還必須處理因在網(wǎng)絡中分布應用程序而引起的通信問題。同樣，操作系統(tǒng)提供商已認識到此種挑戰(zhàn)及潛在的損害并已以各種方式解決此挑戰(zhàn)及潛在損害。例如，Microsoft已通過開發(fā)出分布式組件對象模型(DCOM)來擴展COM功能性。DCOM是一支持分布于一網(wǎng)絡中的目標程序的COM擴展形式。除為COM的擴展形式外，DCOM還提供一處理網(wǎng)絡通信協(xié)議的細節(jié)的接口，以使應用程序設計師能夠著重于其開發(fā)應用專用程序的主要功能。DCOM經(jīng)設計以解決企業(yè)對分布式組件架構(gòu)的要求。例如，一企業(yè)可能想要建立及采用一用戶訂單登記應用程序，所述用戶訂單登記應用程序涉及到數(shù)個不同功能領域的，例如稅款計算、用戶信用驗證、庫存管理、擔保更新及訂單登記。通過使用DCOM，所述應用程序可由五個單獨組件構(gòu)成并可在一通過瀏覽器存取的網(wǎng)絡服務器上運行。每一組件均可駐存于一存取一不同數(shù)據(jù)庫的不同計算機上。程序師可著重于應用程序開發(fā)且DCOM用于處理應用程序中各單獨組件的過程間通信方面。例如，DCOM將處理組件通信與適當隊列的整合及一服務器上的組件應用程序與基于HTML的因特網(wǎng)應用程序的整合。
因此，雖然許多計算機系統(tǒng)操作系統(tǒng)提供商正在提供許多標準化的可執(zhí)行程序模型，但即使這些可執(zhí)行程序也只能在一對一的基礎上介接一媒體源輸入裝置。一旦鏈接至一應用程序，一標準化裝置驅(qū)動文件便不再可供用于另一程序。
一些網(wǎng)絡攝像機供應商(例如新加坡的Creative Labs)使用虛擬源概念，但此是通過向用戶提供一從中進行選擇的多個裝置的選項來實現(xiàn)的。舉例而言，用戶將看到“常規(guī)網(wǎng)絡攝像機”以及一“虛擬”網(wǎng)絡攝像機。如果用戶選擇“常規(guī)”網(wǎng)絡攝像機，則其將無法使用某些視頻效果。然而，如果用戶選擇使用“虛擬”網(wǎng)絡攝像機，則其可使用某些視頻效果。此需要進行不必要的用戶干預并可能使用戶混淆。此外，此并未解決將視頻數(shù)據(jù)自一個源同時提供至多個客戶端應用程序的問題。
此外，當前，無法以一通用方式將多個源無縫地虛擬化成一個源。存在一些其中可以一組合方式輸出來自不同源的媒體數(shù)據(jù)的已知應用程序(例如監(jiān)視系統(tǒng))。然而，此只能通過獲得并使用專門的且昂貴的硬件來實現(xiàn)或在專用軟件應用程序(例如具有專用API)的背景中實現(xiàn)。因此，不存在一種可將來自不同的源的媒體數(shù)據(jù)組合成單個源而不使用專用硬件且可用于任何應用程序的簡單解決方案。
Windows 2000包括一用于虛擬音頻的核心模式Windows驅(qū)動器模塊?？蛻舳耸桥c虛擬音頻源而不是與實際源進行通信。多個客戶端可自同一音頻源接收一音頻流。而且，還提供一混頻系統(tǒng)驅(qū)動器。Microsoft對若干源進行的虛擬化僅限于音頻，而且也不允許對多個音頻源進行虛擬化以向一個或多個客戶端應用程序提供數(shù)據(jù)。
需要使多個應用程序能夠以一種容易且無縫的方式共享單個媒體源輸入裝置(其最常為攝像機或麥克風)，而無需用戶主動地選擇一虛擬裝置來實現(xiàn)此目的。此外，需要能夠?qū)碜远鄠€源的媒體數(shù)據(jù)組合成單個流，然后使所述流可供一個或多個應用程序以一通用且透明的方式使用，且無需使用任何專用硬件。

發(fā)明內(nèi)容本發(fā)明將一可執(zhí)行過程的特征與使多個應用程序共享單個輸入裝置(例如攝像機或麥克風)這一需要相結(jié)合。例如攝像機或麥克風等輸入裝置為外圍裝置，其響應于來自一應用程序的調(diào)用而打開并保持打開。本發(fā)明提供一種構(gòu)建成一使多個應用程序能夠與單個輸入裝置進行通信的過程的可執(zhí)行程序。此是通過為所述實體輸入裝置創(chuàng)建一虛擬接口(一示例)并將所述輸入裝置控制可執(zhí)行程序加載至一過程中來實現(xiàn)。一示例是一加載入存儲器中的實體的實際使用及其一副本的最后虛擬形成。所述可執(zhí)行程序過程用作一服務器，從而使多個應用程序能夠介接同一輸入裝置。此可執(zhí)行程序-其在本文中稱作多實例輸入裝置控制(MIDC)可執(zhí)行程序-響應于每一應用程序請求，仿佛所述輸入裝置是針對所述發(fā)出調(diào)用的應用程序而打開一般。因此，每一應用程序均能夠與所述輸入裝置示例進行通信而不會中斷與同一輸入裝置進行通信的其它應用程序的運行。換句話說，所述MIIDC通過創(chuàng)建一客戶端-服務器架構(gòu)來將一輸入裝置虛擬化，在所述客戶端-服務器架構(gòu)中，每一發(fā)出調(diào)用的應用程序均為一客戶端且其中所述MIIDC為服務器，其向每一發(fā)出調(diào)用的應用程序提供所述驅(qū)動文件。
所述MIIDC及用以將一輸入裝置虛擬化的方法可構(gòu)建于運行各種操作系統(tǒng)的許多計算平臺上。一媒體源輸入裝置(例如一攝像機或一麥克風)通常介接一主計算機。所述主計算機最常為個人計算機，例如通?？墒褂玫腗ac計算機PC。然而，由于技術的進步正使計算裝置與通信裝置之間的界限變得模糊，因此本文所述的主計算機與一智能主機同義，且本文所述的智能主機是指包括任何具有一處理器、存儲器、輸入及輸出構(gòu)件、及存儲構(gòu)件的主機的其它實例。智能主機的其它實例-其也同樣適于與本發(fā)明各實施例結(jié)合使用-包括手持式計算機、交互式機頂盒、薄的客戶端計算裝置、個人存取裝置、個人數(shù)字助理及因特網(wǎng)設備。
在一種位于一運行基于Windows的常見操作系統(tǒng)的PC主機上的實施方式中，所述(MIIDC)可執(zhí)行程序可為一DCOM目標程序。DCOM也可充當一使多個應用程序能夠與單個輸入裝置進行通信的接口。所述DCOM接口處理所有介接操作，例如加載、執(zhí)行、緩沖、卸載及調(diào)用所述可執(zhí)行程序。在所述基于DCOM的實施方式中，所述MIIDC目標程序本身為一DCOM服務器。所述MIIDC程序通過在一構(gòu)建為一可執(zhí)行服務器的DCOM目標程序中連接至所述輸入裝置來起作用。因此，所述MIIDC變成一構(gòu)建為一可執(zhí)行程序的DCOM目標程序，此意味著MIIDC為一可由許多應用程序共享的過程一此類似于任何其它操作系統(tǒng)(O/S)過程。通過將所述輸入裝置存取程序放入一單獨的可執(zhí)行過程中，所述輸入裝置能夠由多個應用程序共享。雖然僅存在所述輸入裝置的一個示例，但所述DCOM接口在所述應用程序看來仿佛其是恰好為調(diào)用所述DCOM目標程序的應用程序打開一般。
MIIDC構(gòu)建成對于每一實際的硬件輸入裝置，所述DCOM服務器均創(chuàng)建單個輸入裝置示例并連接至所述硬件裝置。當一應用程序與所述輸入裝置控制-其為一可執(zhí)行的DCOM服務器-連接時，所述DCOM服務器會創(chuàng)建一MIIDC示例(及一接口)，以使所述應用程序通過其與所述單個輸入裝置示例進行通信。所述單個輸入裝置示例為所述輸入裝置控制的每一示例提供數(shù)據(jù)以供輸出，從而使多個應用程序能夠同時與單個輸入裝置進行通信。全局設定值是針對具體(MIIDC)示例的。另外，所述輸入裝置示例受到保護，以使所述輸入裝置控制程序的多個示例無法執(zhí)行將會妨礙另一示例中的處理的任務。通過使用此種新的方法，可編寫出無需慮及可能已在使用同一輸入裝置的另一應用程序的存在的應用程序。
本發(fā)明的其它方面涉及使一應用程序能夠與輸入裝置服務器可執(zhí)行程序進行通信的客戶端機構(gòu)。如上所述，所述MIIDC可執(zhí)行程序構(gòu)建于一其中每一應用程序均為一客戶端的客戶端-服務器架構(gòu)下。自然地，客戶端必須能夠與服務器進行通信。本發(fā)明的方法提供數(shù)種使一應用程序能夠與所述MIIDC服務器進行通信的機構(gòu)。在一PC/Windows環(huán)境中，一第一客戶端側(cè)機構(gòu)通過一稱作輸入裝置門戶的ActiveX控制來傳送。一同樣處于一PC/Windows環(huán)境下的第二客戶端側(cè)機構(gòu)則通過一DirectShowTM視頻捕捉源濾波器來傳送。
根據(jù)所述門戶方法的所述客戶端側(cè)機構(gòu)包括與所述MIIDC服務器進行通信并向一應用程序提供用戶接口元件。根據(jù)所述門戶方法，用以將一輸入裝置虛擬化的所有功能均由所述MIIDC服務器實施，且因此與所述MIIDC服務器進行通信的應用程序?qū)⑿枰M行用戶接口編程。為實現(xiàn)此目的，根據(jù)所述視頻門戶方法，提供一模板以使不同的應用程序提供商能夠產(chǎn)生其自己的定制的輸入裝置門戶。
根據(jù)所述第二種方法(即DirectShow方法)的客戶端側(cè)機構(gòu)利用稱作濾波器的標準化DirectShow模塊組件。此第二客戶端側(cè)機構(gòu)用一直接與所述MIIDC服務器進行通信的虛擬源濾波器替換標準源(媒體輸入)濾波器。所述虛擬源濾波器對于所述MIIDC服務器而言為一客戶端。借助此機構(gòu)，使一DirectShow應用程序無法區(qū)分“實際的”與“虛擬”的源濾波器。此第二種客戶端側(cè)機構(gòu)的優(yōu)點在于所編寫的用于在一DirectShow環(huán)境中起作用的任何應用程序均將能夠很容易地共享一輸入裝置，而無需進行任何額外的用戶接口編程即能夠與所述MIIDC服務器進行通信。
一根據(jù)本發(fā)明一實施例的系統(tǒng)使單個視頻流能夠無縫地以一種對客戶端/應用程序完全透明的方式暴露至所期望多的客戶端/應用程序。此外，在一實施例中，一根據(jù)本發(fā)明一實施例的系統(tǒng)將來自多個裝置的視頻流組合成單個虛擬流，然后可由所期望多的客戶端存取所述單個虛擬流。在上述發(fā)明的一些實施例中，每一客戶端均可請求一不同的格式及幀速率。此外，在本發(fā)明的一些實施例中，將來自一個或多個源的媒體數(shù)據(jù)提供至一個或多個客戶端應用程序的能力對所述應用程序本身而言是完全透明的。另外，在一根據(jù)本發(fā)明一些實施例的系統(tǒng)中，此實施方式同樣對用戶透明，因為用戶無需選擇任何特定虛擬裝置等等便可獲得此種功能。
為進一步了解本發(fā)明的性質(zhì)和優(yōu)點，應結(jié)合附圖來參閱下文說明。
圖1為一顯示單個應用程序與單個攝像機裝置進行通信的現(xiàn)有技術方法的方塊圖。
圖2為一描繪本發(fā)明多示例輸入裝置控制程序的一實施例的方塊圖。
圖3為一顯示在一應用程序連接至單個輸入裝置時所涉及的各步驟的流程圖。
圖4為一圖解說明其中多個源可與多個應用程序進行通信的本發(fā)明一實施例的方塊圖。
具體實施方式圖2顯示一描繪一處于PC/Windows環(huán)境中的本發(fā)明多示例輸入裝置控制程序(MIIDC)的一實施例的方塊圖。在此實施例中，輸入裝置為一攝像機，且可執(zhí)行程序為一DCOM可執(zhí)行程序服務器。此圖式顯示多個應用程序如何才能共享單個攝像機。一旦一第一應用程序100請求連接至攝像機108，所述請求即傳送至DCOM應用程序接口(API)102。為了更詳細地說明DCOM，可參看適當?shù)腗icrosoft文檔或Microsoft網(wǎng)站。DCOM API 102處理DCOM可執(zhí)行程序的加載并建立一從應用程序到DCOM可執(zhí)行程序200的連接。DCOM服務器200創(chuàng)建單個攝像機示例106及一第一MIIDC示例104。接下來，DCOM服務器200將單個攝像機示例106連接至攝像機驅(qū)動器107，將攝像機驅(qū)動器107連接至攝像機裝置108并將第一MIIDC示例104與所述單個攝像機示例106連接。攝像機示例106為一介接至實體攝像機裝置108的虛擬接口。一實例是一加載入存儲器中的實體的實際使用及其一副本的虛擬創(chuàng)建。在此實施例中，全部示例存儲器位于可執(zhí)行程序服務器中。最后，建立連接300，以使客戶端應用程序100能夠經(jīng)由新近所例示的DCOM接口(單個攝像機示例)106與攝像機裝置108交互作用。
一旦一第二應用程序110請求連接至攝像機108，DCOM服務器200即創(chuàng)建一第二MIIDC示例114，并將其連接至單個攝像機示例106，從而使第二客戶端應用程序110能夠通過已建立的第二連接310經(jīng)由單個攝像機示例106與攝像機裝置108交互作用。隨后的應用程序請求120以及下列等等也通過隨后建立的連接320以及下列等等經(jīng)由DCOM所例示的單個攝像機示例接口106與攝像機裝置108交互作用。
圖3為一描繪圖2所示過程的流程圖。一旦一客戶端應用程序請求連接至攝像機裝置(步驟103)，便將該應用程序的請求發(fā)送至DCOM API(步驟203)。接下來，DCOMAPI判定是否加載由DCOM構(gòu)建的MIIDC可執(zhí)行程序。通常，第一客戶端應用程序使MIIDC可執(zhí)行程序進行加載。如果MIIDC可執(zhí)行程序服務器未得到加載，則DCOMAPI接受該請求并使DCOM服務器加載由DCOM構(gòu)建的MIIDC可執(zhí)行程序服務器(步驟403)。接下來，MIIDC服務器創(chuàng)建一輸入裝置控制示例(步驟503)。如果MIIDC可執(zhí)行程序服務器早已得到加載，則步驟403將變成多余的，且步驟303后的下一步驟將為步驟503。接下來，MIIDC服務器創(chuàng)建單個攝像機示例并將其連接至攝像機裝置，并將輸入裝置控制示例連接至單個攝像機示例(步驟603)。最后，MIIDC服務器創(chuàng)建一接口，通過所述接口使第一客戶端應用程序與所述單個攝像機示例進行通信(步驟703)。
圖2中所描繪的攝像機示例106為一維持輸入裝置控制示例的狀態(tài)的與攝像機裝置的接口。輸入裝置示例106為一維持對已與攝像機裝置建立的連接數(shù)量的必要計數(shù)及這些連接中每一個的特定狀態(tài)的存儲塊。攝像機示例106還包含為對來自每一輸入控制示例連接的請求進行優(yōu)先權(quán)排序及對沖突的請求進行多路復用及解決所必需的邏輯。由于MIIDC服務器以一單獨過程形式存在，因此必須為需要存取視頻(及音頻)數(shù)據(jù)的每一客戶端復制所述視頻(及音頻)數(shù)據(jù)。為了減少數(shù)據(jù)復制，MIIDC服務器設計成記錄視頻(及音頻)、檢測運動、保存圖片、以及一媒體源捕捉裝置通常所具有的其它功能。因此，MIIDC服務器使數(shù)據(jù)復制僅限于那些需要直接存取媒體源(例如視頻及音頻)數(shù)據(jù)的應用。
例如，第一輸入裝置示例可能正在請求一分辨率為640×480像素的視頻流，而第二及第三示例可能正在請求分辨率分別為320×480及160×120像素的視頻流。在此種情形中，攝像機示例106隨后將決定以640×480像素的更大分辨率來捕捉視頻并隨后將其按比例縮小或?qū)⑵浼舻椭恋诙暗谌纠埱蟮?40×480像素的較低分辨率。在同一邏輯之后，如果隨后第一視頻示例與攝像機斷開，則攝像機示例106隨后將通過下述方式來滿足來自第二及第三實例的分別請求320×280及160×120像素分辨率的請求以320×480像素的最高所請求分辨率捕捉視頻以滿足第二示例的請求，并隨后將320×480像素的視頻流按比例縮小或剪低至160×120像素以滿足第三示例的請求。
在涉及三個輸入裝置控制示例的另一實例中，第一輸入裝置控制示例可向虛擬攝像機裝置發(fā)送一運動檢測命令，而其它兩個示例只是在請求視頻流。這時，攝像機示例106將以最高的所要求分辨率捕捉視頻并只通過對第一輸入裝置控制示例的運動檢測計算來傳送該視頻流。
在涉及三個輸入裝置控制示例的再一實例中，第二輸入裝置控制示例可能正在請求一對視頻圖像的文本覆蓋，而另外兩個示例只是在請求視頻流捕捉。這時，攝像機106將以最高所要求的分辨率捕捉視頻并只向流向第二輸入裝置請求的流添加所述文本覆蓋。
雖然到現(xiàn)在為止所述的各實施例均是在一介接個人計算機主機的攝像機情況下來進行大體說明，但本發(fā)明的范圍并非旨在僅限于攝像機或者甚至一特定類型的個人計算機主機。如上所述，本發(fā)明的各實施例涉及通過將一裝置驅(qū)動文件虛擬化來使數(shù)個應用程序同時共享一輸入裝置，而將一裝置驅(qū)動文件虛擬化又是通過將輸入裝置控制程序構(gòu)建成一可執(zhí)行程序服務器來實現(xiàn)的。雖然上述輸入裝置為一攝像機，但另一可配置成被同時共享的輸入裝置為麥克風。因此，輸入裝置示例(圖2中的106)包含為將來自每一輸入裝置控制示例的請求按優(yōu)先權(quán)排序及對沖突請求進行多路復用及解決所必需的邏輯。將視頻源的共享能力擴展成還包括一音頻輸入源不僅是正常的，而且也幾乎是強制性的，因為視頻與音頻最常見的是作為自然互補的媒體源捆綁在一起。
例如，重新參見圖2，預計需要考慮在裝置108正在記錄視頻的同時一麥克風(未顯示)也在記錄聲音的情形。此時，例如，第一輸入裝置示例可能正在請求在44.1kHz下位深度為16位的音頻，而第二示例可能正在請求在11.025kHz下位深度為8位的音頻流。在此種情形中，輸入裝置示例將隨后決定以最高采樣速率及位深度捕捉音頻并隨后將其按比例縮小或壓低至第二示例所請求的較低位深度或采樣速率。
MIIDC及用以將一輸入裝置虛擬化的方法可構(gòu)建于運行各種操作系統(tǒng)的許多計算平臺上。一媒體源輸入裝置(例如一攝像機或一麥克風)通常介接一主計算機。所述主計算機最常為個人計算機，例如通?？墒褂玫腗ac計算機PC。然而，由于技術的進步正使計算裝置與通信裝置之間的界限變得模糊，因此本文所用的主計算機與一智能主機同義，且本文所用的智能主機是指包括任何具有一處理器、存儲器、輸入及輸出構(gòu)件、及存儲構(gòu)件的主機的其它實例。智能主機的其它實例-其也同樣適于與本發(fā)明各實施例結(jié)合使用-包括手持式計算機、交互式機頂盒、薄的客戶端計算裝置、個人存取裝置、個人數(shù)字助理及因特網(wǎng)設備。
本發(fā)明的其它方面涉及使一應用程序能夠與所述輸入裝置服務器可執(zhí)行程序進行通信的客戶端側(cè)機構(gòu)。如上所述，所述MIIDC可執(zhí)行程序構(gòu)建于一其中每一應用程序均為一客戶端的客戶端-服務器架構(gòu)下。因此，客戶端必須能夠與服務器進行通信。本發(fā)明的方法提供數(shù)種使一應用程序能夠與所述MIIDC服務器進行通信的機構(gòu)。在一PC/Windows環(huán)境中，一第一客戶端側(cè)機構(gòu)通過一稱作輸入裝置門戶的ActiveX控制來傳送。一同樣處于一PC/Windows環(huán)境下的第二客戶端側(cè)機構(gòu)則通過一DirectShow視頻捕捉源濾波器來傳送。
根據(jù)所述門戶方法的所述客戶端側(cè)機構(gòu)包括與所述MIIDC服務器進行通信并向一應用程序提供用戶接口元件。根據(jù)所述門戶方法，用以將一輸入裝置虛擬化的所有功能均由所述MIIDC服務器實施，且因此與所述MIIDC服務器進行通信的應用程序?qū)⑿枰M行用戶接口編程。為實現(xiàn)此目的，根據(jù)所述視頻門戶方法，提供一模板以使不同的應用程序提供商能夠產(chǎn)生其自己的定制的輸入裝置門戶。
根據(jù)所述第二種方法(即DirectShow方法)的客戶端側(cè)機構(gòu)利用稱作濾波器的標準化DirectShow模塊組件。由MicrosoftTM提供的DirectShowTM服務能為多媒體流提供回放服務，包括從裝置中捕捉多媒體流。DirectShowTM服務的核心是一由稱作濾波器的可插式組件構(gòu)成的模塊系統(tǒng)。
這些模塊組件可分為源、轉(zhuǎn)換及再現(xiàn)。濾波器通過將數(shù)據(jù)讀取、復制、修改或?qū)懭胫烈晃募谢驅(qū)⑺鑫募佻F(xiàn)至一輸出裝置上來處理數(shù)據(jù)流。所述濾波器具有輸入及輸出構(gòu)件并彼此連接成一稱作濾波器圖的結(jié)構(gòu)。應用程序使用一稱作濾波器圖管理器的目標程序來匯編所述濾波器圖并通過其來移動數(shù)據(jù)。濾波器圖管理器處理從一輸入裝置到所述回放裝置的數(shù)據(jù)流?？赏ㄟ^參看所屬領域的技術人員所知的適當文檔來獲得對DirectShowTM服務及MicrosoftTMDirectXTM媒體軟件開發(fā)工具包的進一步說明。
此第二客戶端側(cè)機構(gòu)用一直接與所述MIIDC服務器進行通信的虛擬源濾波器替換標準源(媒體輸入)濾波器。所述虛擬源濾波器對于所述MIIDC服務器而言為一客戶端。借助此機構(gòu)，使一DirectShow應用程序無法區(qū)分“實際的”與“虛擬”的源濾波器。此第二種客戶端側(cè)機構(gòu)的優(yōu)點在于所編寫的用于在一DirectShow環(huán)境中起作用的任何應用程序均將能夠很容易地共享一輸入裝置，而無需進行任何額外的用戶接口編程即能夠與所述MIIDC服務器進行通信。
圖4為一圖解說明一其中可向一個或多個應用程序提供來自一個或多個源的視頻及其它媒體數(shù)據(jù)的本發(fā)明實施例的方塊圖。所述方塊圖包括媒體源410、媒體數(shù)據(jù)客戶端應用程序430及一虛擬源420。
有數(shù)個源410a、410b、...，410m可提供多媒體數(shù)據(jù)。這些數(shù)據(jù)源可為可捕捉某些類型的多媒體數(shù)據(jù)(例如視頻及/或靜止圖像)的數(shù)據(jù)捕捉裝置。多媒體數(shù)據(jù)源410的實例包括外圍裝置，例如麥克風、獨立攝像機、網(wǎng)絡攝像機、數(shù)字照相機、及/或其它視頻/音頻捕捉裝置。在一實施例中，某些源410是由Logitech公司(Fremont，CA)提供的QuickCam網(wǎng)絡攝像機。所述數(shù)據(jù)可通過一設置于標準或定制的計算機上的BluetoothTM/IR接收機、無線USB、或各種輸入/輸出接口在一無線連接上提供。所述數(shù)據(jù)流可發(fā)送至一數(shù)據(jù)槽，例如一文件、揚聲器、客戶端應用程序或裝置。
有數(shù)個客戶端應用程序430a、430b，...，430n需要使用源410所提供的數(shù)據(jù)?？蛻舳藨贸绦?30可為任一對源430而言為客戶端的用戶。在一實施例中，一些客戶端應用程序430為Instant Messager(IM)。當前可使用的IM程序的一些實例為Microsoft公司(Redmond，WA)的MSNMessenger、由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等通信應用程序、視頻編輯應用程序、或任何其它類型的通用或?qū)Ｓ枚嗝襟w應用程序。
虛擬源420連接至源410并自其請求數(shù)據(jù)。然后，虛擬源420根據(jù)需要對此數(shù)據(jù)進行處理、復制及格式化，然后向客戶端應用程序430提供一個流。
在一實施例中，虛擬源420創(chuàng)建于所述源410所附接到的且上面駐存有客戶端應用程序430的主機(例如一計算機系統(tǒng))上。在一實施例中，虛擬源420創(chuàng)建于核心模式中。在一實施例中，虛擬源420使源410能夠?qū)蛻舳藨贸绦?30完全透明。源410對客戶端應用程序430完全隱藏，且因此客戶端應用程序430完全不知曉源410的存在?？蛻舳藨贸绦?qū)λ杳襟w裝置(攝像機等)的調(diào)用基本上被選路至本發(fā)明的虛擬裝置-其在系統(tǒng)總線上自行登記為所需裝置。一WDM總線枚舉器附接至根總線。因此，此枚舉器自身在引導時(或在安裝時)與所有其它根枚舉裝置一起由操作系統(tǒng)進行枚舉。此枚舉器負責管理一虛擬裝置總線。為此，其監(jiān)控將要虛擬化的實體裝置的到達與離開并為其發(fā)現(xiàn)的每一實體裝置枚舉一虛擬裝置。
換句話說，一客戶端應用程序430無法分辨其正在與除一正常源外的任何事物進行通信。此外，用戶也無法分辨他/她正在與一擬虛源420交互作用。根據(jù)本發(fā)明的一實施例，為使用一系統(tǒng)，用戶不需要選擇任何替代虛擬裝置。更確切地說，用戶的體驗是完全無縫且透明的。
在一實施例中，客戶端應用程序430仍然完全不知道來自數(shù)據(jù)源410的數(shù)據(jù)流的原始格式/內(nèi)容。因此，一根據(jù)本發(fā)明一實施例的系統(tǒng)可接收各種各樣的格式及內(nèi)容。在一實施例中，基本源410不支持客戶端應用程序430所請求的幀速率及/或格式。本發(fā)明的視頻驅(qū)動器發(fā)送控制信號來選擇實體攝像機的所需格式及其它可控制特征。例如，可設定任一客戶端正在請求的最高分辨率及幀速率，以使虛擬驅(qū)動器可為其他請求那些不同值的客戶端產(chǎn)生較低的幀速率及分辨率。其它參數(shù)可因客戶端而異，例如電子聚焦、掃視及俯仰。
所述數(shù)據(jù)流可呈各種格式中的任何一種。例如，視頻流可經(jīng)過壓縮或解壓縮，并呈各種格式中的任何一種，包括RGB、YUV、MJPEG、各種MPEG格式(例如MPEG1、MPEG2、MPEG4、MPEG7等等)、WMF(WindowsMedia Format)、RM(Real Media)、Quicktime、Shockwave及其它格式。最后，所述數(shù)據(jù)還可呈AVI(音頻視頻交錯)格式。
在一實施例中，虛擬源420評定并確定用以自源410獲得數(shù)據(jù)的最適當格式以便將所述數(shù)據(jù)提供至客戶端應用程序430。在一實施例中，各客戶端應用程序430請求不同的格式及/或幀速率，且虛擬源420可滿足每一客戶端應用程序430的請求。在一實施例中，將來自不同的源410的多個視頻流組合成一個來自虛擬源420的虛擬流，然后可由一個或多個客戶端應用程序430存取所述虛擬流，其中每一客戶端均可能請求一不同的格式及幀速率。
在本發(fā)明的一些實施例中，該實施方案將僅適用于特定源而不適用于其它源。例如，一根據(jù)本發(fā)明一實施例的實施方案可僅適用于來自一特定提供商的網(wǎng)絡攝像機而不適用于來自其它提供商的網(wǎng)絡攝像機。在一實施例中，對所述源(要虛擬化的裝置)使用加密的信號交換，以便通過此種方式只可使用某些源。
在一實施例中，可向一應用程序提供多個視頻源，所述應用程序?qū)⒉⑴棚@示這些視頻源或?qū)⑵滹@示于單獨的觀察窗口中。例如，在保安應用中可通過一由所顯示的不同攝像機圖像組成的組合畫面來對多個攝像機進行監(jiān)控。或者，可使用單個攝像機的兩個圖像傳感器來捕捉基本相同的景物。其中一個圖像傳感器可為一用于視頻或運動檢測的低分辨率傳感器，而另一傳感器可為一用于靜止圖像的高分辨率傳感器。或者，可使用一攝像機中取自不同位置的圖像或取自多個攝像機的圖像來構(gòu)造一3維(3D)圖像或視頻。所述3D圖像可構(gòu)造于驅(qū)動器中，或構(gòu)造于客戶端應用程序中。在另一實施例中，可使圖像在驅(qū)動器或客戶端應用程序中彼此疊加。這樣做可能是為了例如在一個人背后放置不同的背景。
所屬技術領域：
的技術人員將理解，本發(fā)明也可實施為其它具體形式，此并不背離其基本特征。例如，在本發(fā)明的各實施例中，并非處理視頻及音頻數(shù)據(jù)，而是可處理靜止圖像數(shù)據(jù)，或除處理視頻及音頻數(shù)據(jù)以外，還可處理靜止圖像數(shù)據(jù)。這些其它實施例也打算包括于在隨附權(quán)利要求
書中所規(guī)定的本發(fā)明范圍內(nèi)。
權(quán)利要求
1.一種用于透明地向復數(shù)個客戶端應用程序提供多媒體數(shù)據(jù)的系統(tǒng)，所述系統(tǒng)包括一提供所述多媒體數(shù)據(jù)的數(shù)據(jù)源；一使用所述多媒體數(shù)據(jù)的第一客戶端應用程序；一使用所述多媒體數(shù)據(jù)的第二客戶端應用程序；一以通信方式耦合至所述數(shù)據(jù)源及所述第一及第二客戶端應用程序的虛擬數(shù)據(jù)源，其中所述虛擬源從所述數(shù)據(jù)源獲得所述多媒體數(shù)據(jù)，并將所述多媒體數(shù)據(jù)提供至所述第一客戶端應用程序及所述第二客戶端應用程序。
2.如權(quán)利要求
1所述的系統(tǒng)，其中所述多媒體數(shù)據(jù)為視頻數(shù)據(jù)。
3.如權(quán)利要求
2所述的系統(tǒng)，其中所述數(shù)據(jù)源為一網(wǎng)絡攝像機。
4.如權(quán)利要求
1所述的系統(tǒng)，其中所述第一客戶端應用程序為一即時消息接發(fā)應用程序。
5.如權(quán)利要求
1所述的系統(tǒng)，其中所述虛擬源位于核心模式中。
6.如權(quán)利要求
1所述的系統(tǒng)，其進一步包括一以通信方式耦合至所述虛擬源的第二數(shù)據(jù)源，其中所述第一客戶端應用程序接收一將來自所述第一數(shù)據(jù)源與所述第二數(shù)據(jù)源的數(shù)據(jù)相組合的單個數(shù)據(jù)流。
7.如權(quán)利要求
1所述的系統(tǒng)，其中所述第一客戶端應用程序請求一不同于由所述數(shù)據(jù)源提供的數(shù)據(jù)格式的數(shù)據(jù)格式。
8.如權(quán)利要求
7所述的系統(tǒng)，其中所述虛擬源確定要自所述數(shù)據(jù)源接收的所述數(shù)據(jù)的所述格式以便能夠有效地創(chuàng)建所述客戶端應用程序所請求的所述數(shù)據(jù)的所述格式。
9.如權(quán)利要求
1所述的系統(tǒng)，其中所述第一客戶端應用程序請求一不同于所述數(shù)據(jù)源所提供的數(shù)據(jù)的幀速率的數(shù)據(jù)幀速率。
10.一種用于透明地將多媒體數(shù)據(jù)自復數(shù)個數(shù)據(jù)源提供至一客戶端應用程序的系統(tǒng)，所述系統(tǒng)包括一提供第一多媒體數(shù)據(jù)的第一數(shù)據(jù)源；一提供第二多媒體數(shù)據(jù)的第二數(shù)據(jù)源；一以通信方式耦合至所述第一數(shù)據(jù)源及所述第二數(shù)據(jù)源并耦合至所述客戶端應用程序的虛擬數(shù)據(jù)源，其中所述虛擬源獲得來自所述第一數(shù)據(jù)源的所述第一多媒體數(shù)據(jù)及來自所述第二數(shù)據(jù)源的所述第二多媒體數(shù)據(jù)，并向所述客戶端應用程序提供一將所述第一多媒體數(shù)據(jù)與所述第二多媒體數(shù)據(jù)相組合的單個數(shù)據(jù)流。
11.一種用于向復數(shù)個客戶端應用程序提供多媒體數(shù)據(jù)的方法，其中所述多媒體數(shù)據(jù)由一數(shù)據(jù)源提供，其中處理對所述復數(shù)個客戶端應用程序是透明的，所述方法包括通過一虛擬源來獲得由所述數(shù)據(jù)源提供的所述數(shù)據(jù)；修改所述數(shù)據(jù)的幀速率或格式中的一者；及將所述經(jīng)修改的多媒體數(shù)據(jù)提供至所述復數(shù)個客戶端應用程序中的每一個。
12.如權(quán)利要求
11所述的方法，其中所述多媒體數(shù)據(jù)為視頻數(shù)據(jù)。
13.如權(quán)利要求
11所述的方法，其中所述多媒體數(shù)據(jù)為靜止圖像數(shù)據(jù)。
14.一種用于透明地將多媒體數(shù)據(jù)自復數(shù)個數(shù)據(jù)源提供至一客戶端應用程序的方法，所述方法包括通過一虛擬源自第一數(shù)據(jù)源獲得第一多媒體數(shù)據(jù)；通過所述虛擬源自第二數(shù)據(jù)源獲得第二多媒體數(shù)據(jù)；組合所述第一多媒體數(shù)據(jù)與所述第二多媒體數(shù)據(jù)以創(chuàng)建一單個數(shù)據(jù)流；及將所述單個數(shù)據(jù)流提供至所述客戶端應用程序。
15.如權(quán)利要求
14所述的方法，其中所述第一多媒體數(shù)據(jù)為一來自一攝像機中一第一圖像傳感器的第一視頻圖像且所述第二多媒體數(shù)據(jù)為一來自所述攝像機中一第二圖像傳感器的第二視頻圖像。
16.如權(quán)利要求
15所述的方法，其中所述第一視頻圖像為低分辨率且所述第二視頻圖像為高分辨率。
17.如權(quán)利要求
14所述的方法，其進一步包括自所述第一及第二視頻圖像創(chuàng)建一三維圖像。
18.一種包括一用于促成對一輸入裝置的同時共享的計算機程序的計算機可用媒體，所述程序包括，調(diào)用代碼，其用于響應于一自一第一應用程序接收到的請求存取所述單個輸入裝置的第一存取請求來調(diào)用一輸入裝置控制程序；關聯(lián)代碼，其用于在根據(jù)所述輸入裝置控制程序創(chuàng)建所述單個輸入裝置示例后即刻使一單個輸入裝置示例與所述單個輸入裝置相關聯(lián)；產(chǎn)生代碼，其用于響應于所述第一請求而產(chǎn)生一第一控制示例，所述第一控制示例與所述第一應用程序相關聯(lián)；關聯(lián)代碼，其用于將所述第一控制示例與所述單個輸入裝置示例相關聯(lián)，以便所述第一應用程序可使用所述第一控制示例與所述單個輸入裝置示例之間的所述關聯(lián)來存取所述單個輸入裝置；產(chǎn)生代碼，其用于響應于一自一第二應用程序接收到的請求存取所述單個輸入裝置的第二存取請求來產(chǎn)生一第二控制示例；及關聯(lián)代碼，其用于使所述第二控制示例與所述單個輸入裝置示例相關聯(lián)，以便所述第二應用程序可使用所述第二控制示例與所述單個輸入裝置示例之間的所述關聯(lián)來存取所述單個輸入裝置。
專利摘要
本發(fā)明使單個媒體流能夠以一種對客戶端/應用程序完全透明的方式無縫地暴露至所期望多的客戶端/應用程序。此外，本發(fā)明的一實施例將來自多個裝置(例如網(wǎng)絡攝像機、麥克風、等等)的媒體流組合成一單個虛擬流，隨后可由所期望多的客戶端存取所述單個虛擬流。在本發(fā)明的一些實施例中，每一客戶端均可請求一不同的格式及幀速率。此外，在本發(fā)明的一些實施例中，將來自一個或多個源的媒體數(shù)據(jù)提供給一個或多個客戶端應用程序的能力對所述應用程序以及用戶完全透明。
文檔編號H04N7/173GK1992619SQ200610152466
公開日2007年7月4日 申請日期2006年9月29日
發(fā)明者阿諾·格拉特龍, 阿龍·斯坦里奇, 蒂姆·迪克曼 申請人:羅技歐洲公司導出引文BiBTeX, EndNote, RefMan