專利名稱：透明地處理多媒體數(shù)據(jù)的系統(tǒng)與方法
技術(shù)領(lǐng)域：
本發(fā)明大體上是關(guān)于多媒體數(shù)據(jù)處理，且明確地說是關(guān)于用于智能地且透明地實(shí)時(shí)處理多媒體流的用戶模式多媒體處理層。
背景技術(shù)：
在過去幾年中，人們互相以電子方式建立的聯(lián)系已經(jīng)大大增加。人們使用多種通信模式互相以電子方式通信，所述模式例如電子郵件、文本通訊等。尤其是實(shí)時(shí)視頻和音頻通信(例如IM聊天，包括視頻和/或音頻聊天)已變得很普遍。
為了進(jìn)行視頻和音頻實(shí)時(shí)聊天，常把照相機(jī)(常稱為網(wǎng)絡(luò)照相機(jī))連接到用戶的計(jì)算機(jī)，并把照相機(jī)捕捉到的視頻和/或音頻數(shù)據(jù)傳輸?shù)剿鲇?jì)算機(jī)。用戶有幾個(gè)選擇傳輸靜止圖像、視頻和/或音頻數(shù)據(jù)，如即時(shí)通訊(IM)、現(xiàn)場直播的視頻流、為了創(chuàng)建電影而進(jìn)行的視頻捕捉、視頻監(jiān)視、因特網(wǎng)監(jiān)視、因特網(wǎng)網(wǎng)絡(luò)照相機(jī)等。對于這些用途在市場上有多種客戶端應(yīng)用程序。例如，只對即時(shí)通訊而言，用戶可從幾個(gè)應(yīng)用程序選擇，所述應(yīng)用程序包括微軟公司(Redmond，WA)的MSN通訊軟件、ICQ公司的ICQ、美國在線公司(Dulles，VA)的美國在線即時(shí)通訊軟件(AIM)，和雅虎公司(Sunnyvale，CA)的Yahoo！即時(shí)通訊軟件。
用戶常希望以某些方式改變視頻和/或音頻流。由于多種原因，可能希望進(jìn)行這些修改。例如，用戶可能想要看上去和/或聽上去像另外一個(gè)人(例如，像某個(gè)名人，某個(gè)動(dòng)畫角色等)。另一個(gè)例子是當(dāng)用戶只希望不被認(rèn)出而保持匿名。又一個(gè)例子是當(dāng)用戶想要看上去像他自己的更好一面(例如，用戶可能沒有為業(yè)務(wù)會(huì)議而盛裝打扮，但他想要表現(xiàn)得專業(yè))。又一個(gè)例子是當(dāng)用戶想要?jiǎng)?chuàng)建視頻和/或音頻特殊效果時(shí)。由于這些原因和各種其他原因，用戶常希望修改由他們的網(wǎng)絡(luò)照相機(jī)和/麥克風(fēng)實(shí)際上捕捉到的視頻和/或音頻流。在一個(gè)例子中，用戶有一個(gè)他們選擇的化身。已公布的美國申請案20030043153描述一種用于修改化身的系統(tǒng)。
常規(guī)視頻和音頻處理系統(tǒng)不能自動(dòng)地且透明地執(zhí)行這些修改可能需要的適當(dāng)處理功能。現(xiàn)有的系統(tǒng)在很大程度上是不透明的，需要配置下游應(yīng)用程序以便利用視頻和/或音頻修改能力。常見的情況是需要把處理組件并入客戶端應(yīng)用程序中，以便實(shí)施這些修改。這些處理組件是專用處理組件?；蛘?，需要使用第三方組件來向系統(tǒng)流搶先添加經(jīng)處理的輸出。又一個(gè)選擇是在多媒體數(shù)據(jù)捕捉裝置的驅(qū)動(dòng)程序中引入視頻和/或音頻修改能力。然而，客戶端應(yīng)用程序仍將需要進(jìn)行選擇來施加效果，且將必須定制每個(gè)裝置的驅(qū)動(dòng)程序以便并入所述功能性。此外，在驅(qū)動(dòng)程序中不可能進(jìn)行高級(jí)處理，因?yàn)榄h(huán)境中沒有這些高級(jí)處理所需的適當(dāng)服務(wù)。另外，驅(qū)動(dòng)程序中的一切事物都是很靜止的，且需要大量的測試來保證系統(tǒng)穩(wěn)定性，從而使得幾乎不可能在驅(qū)動(dòng)程序中提供靈活且可擴(kuò)展的架構(gòu)。另外，如果處理功能性在驅(qū)動(dòng)程序中，那么除非用戶為裝置下載新的驅(qū)動(dòng)程序，否則不能實(shí)現(xiàn)與現(xiàn)有裝置和驅(qū)動(dòng)程序的向后兼容性。
需要一種系統(tǒng)與方法，其可以透明地實(shí)時(shí)修改靜止圖像、視頻和/或音頻流，而獨(dú)立于所使用的特殊客戶端應(yīng)用程序，且不需要修改裝置的驅(qū)動(dòng)程序。

發(fā)明內(nèi)容
本發(fā)明是一種透明地實(shí)時(shí)處理視頻和/或音頻流的多媒體數(shù)據(jù)處理系統(tǒng)與方法。根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)的操作不需要任何來自視頻和/或音頻流制作者或客戶端應(yīng)用程序的干涉或牽涉。使用這種透明解決方案，可以無縫地處理視頻和/或音頻流，且完全獨(dú)立于用戶選擇使用的特殊客戶端應(yīng)用程序。因此，根據(jù)本發(fā)明的一些實(shí)施例的系統(tǒng)可與用戶選擇的任何客戶端應(yīng)用程序一起使用。這允許為最終用戶的利益創(chuàng)建大量視頻和/或音頻效果和/或改進(jìn)。
在一實(shí)施例中，由用戶模式視頻處理層(UMVPL)或用戶模式音頻處理層(UMAPL)執(zhí)行對多媒體數(shù)據(jù)的處理。在一實(shí)施例中，UMVPL或UMAPL位于在多媒體源或多媒體槽與客戶端應(yīng)用程序之間的多媒體數(shù)據(jù)路徑上。處理層位于用戶模式中，而不是內(nèi)核模式中。內(nèi)核是非常有限且敏感的環(huán)境，且其沒有施加高級(jí)效果所需的許多服務(wù)，尤其是對于視頻而言。另外，在內(nèi)核中容易使系統(tǒng)崩潰；用戶模式環(huán)境要安全得多。此外，當(dāng)在用戶模式中時(shí)，對于每個(gè)程序而言可改變視頻和/或音頻流。因此，用戶可為每個(gè)單獨(dú)進(jìn)程(應(yīng)用程序)引入一組不同的效果，或者只選擇在一個(gè)進(jìn)程中產(chǎn)生效果而其他進(jìn)程保持不受影響。最后，對于多媒體流內(nèi)核模式的入口非常局限性，且因此其可以被攔截。當(dāng)代碼在內(nèi)核中時(shí)，要進(jìn)行攔截就困難得多。
在一實(shí)施例中，根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)包括進(jìn)程創(chuàng)建監(jiān)控器，和注入器服務(wù)(Injector Service)以及UMVPL或UMAPL。進(jìn)程創(chuàng)建監(jiān)控器監(jiān)控每個(gè)已創(chuàng)建進(jìn)程，并告知注入器服務(wù)。這個(gè)注入器服務(wù)隨后向每個(gè)進(jìn)程注入一注入器鉤子庫(注入器鉤子動(dòng)態(tài)鏈接庫(DLL))。這些鉤子又在多媒體數(shù)據(jù)到達(dá)其目的地之前經(jīng)由UMVPL或UMAPL重新路由每個(gè)進(jìn)程。
在一實(shí)施例中，多媒體數(shù)據(jù)源可為用戶的裝置(如網(wǎng)絡(luò)照相機(jī)、麥克風(fēng)等)，且目的地可為客戶端應(yīng)用程序。在另一實(shí)施例中，多媒體數(shù)據(jù)流的方向可從客戶端應(yīng)用程序到用戶的裝置(例如視頻輸出裝置(例如記錄設(shè)備)、揚(yáng)聲器等)。
在一實(shí)施例中，本發(fā)明使用外部服務(wù)來監(jiān)控新進(jìn)程并向這些進(jìn)程添加代碼。本發(fā)明通過熱修補(bǔ)內(nèi)存中的軟件并通過只考慮選擇服務(wù)調(diào)用來插入所述系統(tǒng)中。這種解決方案因此是通用的。所述系統(tǒng)可施加一連串效果。
本說明書中描述的特征和優(yōu)點(diǎn)不包括所有特征和優(yōu)點(diǎn)，且尤其是，考慮到圖示、說明書和權(quán)利要求書，所屬領(lǐng)域的技術(shù)人員將明了許多額外特征和優(yōu)點(diǎn)。此外，應(yīng)注意在說明書中使用的語言主要是為易讀性和指導(dǎo)性目的而選擇的，且不是選擇用來描繪或限制本標(biāo)的物。


本發(fā)明具有其他優(yōu)點(diǎn)和特征，根據(jù)本發(fā)明的以下具體實(shí)施方式
和隨附權(quán)利要求書(當(dāng)結(jié)合附圖來看時(shí))，所述優(yōu)點(diǎn)和特征將更為顯而易見，圖1是說明連接到主機(jī)的視頻/音頻捕捉裝置如何使用客戶端應(yīng)用程序來與另一類似裝備在網(wǎng)絡(luò)上通信的方框圖。
圖2A說明來自圖1的系統(tǒng)的一側(cè)的一實(shí)施例。
圖2B是說明以上參考圖2A描述的系統(tǒng)中的數(shù)據(jù)流的方框圖。
圖3A是說明根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)的方框圖。
圖3B是說明根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)中的數(shù)據(jù)流的方框圖。
圖4A、4B和4C是描述在根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)中從打開客戶端應(yīng)用程序開始，然后打開視頻流到關(guān)閉所述流的特殊例子的流程圖。
圖5是大體上確定由根據(jù)本發(fā)明的一實(shí)施例的進(jìn)程創(chuàng)建監(jiān)控器、注入器服務(wù)和UMVPL進(jìn)行的步驟的流程圖。
圖6是對注入器鉤子部分比圖3B更詳細(xì)地展示一架構(gòu)實(shí)施例的多種組件及其關(guān)系的圖。
圖7是展示根據(jù)本發(fā)明的一實(shí)施例的視頻幀的典型數(shù)據(jù)流的圖。
具體實(shí)施例方式
將詳細(xì)參考本發(fā)明的若干實(shí)施例。盡管將主要參考使用標(biāo)準(zhǔn)Windows內(nèi)核流協(xié)議的多媒體裝置的Windows環(huán)境中的透明視頻/音頻處理系統(tǒng)的實(shí)施，但是所屬領(lǐng)域技術(shù)人員知道，相同的概念可在包括Linux、Mac OS或其它專有或公開操作系統(tǒng)平臺(tái)(包括實(shí)時(shí)操作系統(tǒng))的各種操作環(huán)境中的任一種操作環(huán)境中實(shí)施。請注意，盡管一些實(shí)施例在視頻處理的情況下加以論述，但是這些實(shí)施例也可應(yīng)用于任何類型的多媒體處理(例如，音頻、靜止圖像等)。另外，應(yīng)注意，盡管一些實(shí)施例使多媒體源為用戶裝置且使數(shù)據(jù)槽(data sink)為客戶端應(yīng)用程序來加以論述，但是可在這些實(shí)施例中時(shí)使數(shù)據(jù)流反向。
圖1是說明連接到主機(jī)的視頻/音頻捕獲裝置可如何使用客戶端應(yīng)用程序來經(jīng)由網(wǎng)絡(luò)與另一類似裝備(setup)通信的方框圖。所述常規(guī)系統(tǒng)可由用戶用于彼此傳輸多媒體信息。系統(tǒng)100包含數(shù)據(jù)捕獲裝置110a和110b、計(jì)算機(jī)系統(tǒng)120a和120b、網(wǎng)絡(luò)130和客戶端應(yīng)用服務(wù)器140。數(shù)據(jù)捕獲裝置110a和110b可以是可連接到計(jì)算機(jī)系統(tǒng)120a和120b且可捕獲一些類型的多媒體數(shù)據(jù)(例如，視頻、音頻和/或靜止圖像)的任何所述裝置。舉例而言，數(shù)據(jù)捕獲裝置110a和110b可以是網(wǎng)絡(luò)照相機(jī)、數(shù)字靜止照相機(jī)、麥克風(fēng)等。在一個(gè)實(shí)施例中，數(shù)據(jù)捕獲裝置110a和/或110b是Logitech，Inc.(Fremont，CA)的QuickCam網(wǎng)絡(luò)照相機(jī)。
主機(jī)120a和120b是常規(guī)的計(jì)算機(jī)系統(tǒng)，其可各自包括可耦接到計(jì)算機(jī)系統(tǒng)的計(jì)算機(jī)、存儲(chǔ)裝置、網(wǎng)絡(luò)服務(wù)連接和常規(guī)輸入/輸出裝置(如顯示器、鼠標(biāo)、打印機(jī)和/或鍵盤)。在一個(gè)實(shí)施例中，計(jì)算機(jī)還包括常規(guī)操作系統(tǒng)、輸入/輸出裝置和網(wǎng)絡(luò)服務(wù)軟件。另外，在一個(gè)實(shí)施例中，計(jì)算機(jī)包括可與客戶端應(yīng)用服務(wù)器140通信的客戶端應(yīng)用軟件。網(wǎng)絡(luò)服務(wù)連接包括允許連接到常規(guī)網(wǎng)絡(luò)服務(wù)的那些硬件和軟件組件。舉例而言，網(wǎng)絡(luò)服務(wù)連接可包括到電信線的連接(例如，撥號(hào)、數(shù)字用戶線路(“DSL”)、T1或T3通信線路)。主機(jī)計(jì)算機(jī)、存儲(chǔ)裝置和網(wǎng)絡(luò)服務(wù)連接可從(例如)IBM公司(Armonk，NY)、Sun Microsystems，Inc.(Palo Alto，CA)或Hewlett-Packard，Inc.(Palo Alto，CA)購得。
網(wǎng)絡(luò)130可以是任何網(wǎng)絡(luò)，如廣域網(wǎng)(WAN)或局域網(wǎng)(LAN)或任何其它網(wǎng)絡(luò)。WAN可包括因特網(wǎng)、因特網(wǎng)2和其類似物。LAN可包括內(nèi)網(wǎng)，其可以是基于(例如)TCP/IP屬于一個(gè)組織且僅可由組織的成員、員工或經(jīng)授權(quán)的其它人訪問的網(wǎng)絡(luò)。LAN也可以是如Novell公司(Provo，UT)的NetwareTM或微軟公司(Redmond，WA)的WindowsNT的網(wǎng)絡(luò)。網(wǎng)絡(luò)120也可包括市售的基于預(yù)訂的服務(wù)，如美國在線公司(Dulles，VA)的AOL或微軟公司(Redmond，WA)的MSN。
一些客戶端應(yīng)用程序需要客戶端服務(wù)器140。下文中參考圖2A論述客戶端應(yīng)用程序。
圖2A說明上述系統(tǒng)100的一側(cè)的一個(gè)實(shí)施例。如上所述，這包含數(shù)據(jù)捕獲裝置110和主機(jī)120。為了容易論述，以下論述參考視頻數(shù)據(jù)的捕獲和處理。如上所提及，請注意，其它類型的多媒體數(shù)據(jù)(例如，音頻和靜止圖像數(shù)據(jù))在多種實(shí)施例中以多種方式處理。在一個(gè)實(shí)施例中，由數(shù)據(jù)捕獲裝置所需的驅(qū)動(dòng)程序210、視頻捕獲應(yīng)用程序接口(API)220和用戶選擇來使用的客戶端應(yīng)用程序230存在于主機(jī)120上。
上文已參考圖1描述了數(shù)據(jù)捕獲裝置110和主機(jī)120。驅(qū)動(dòng)程序210是控制數(shù)據(jù)捕獲裝置110的程序。驅(qū)動(dòng)程序210可與主機(jī)上的操作系統(tǒng)一起出現(xiàn)，或可需要從因特網(wǎng)上下載，或從數(shù)據(jù)捕獲裝置110所附的CD下載等。驅(qū)動(dòng)程序210用作視頻捕獲裝置110與主機(jī)120上的操作系統(tǒng)之間的翻譯程序。每一視頻捕獲裝置110具有其自己的專用命令集，僅其驅(qū)動(dòng)程序210知道這個(gè)專用命令集。另一方面，大多數(shù)操作系統(tǒng)通過使用通用命令訪問視頻捕獲裝置110。因此，驅(qū)動(dòng)程序210需要從主機(jī)120上的操作系統(tǒng)接受通用命令，且將它們翻譯成視頻捕獲裝置110可理解的專用命令。驅(qū)動(dòng)程序210也用作視頻捕獲裝置110與使用數(shù)據(jù)捕獲裝置110的視頻捕獲API 220之間的接口。
視頻捕獲API 220是達(dá)成驅(qū)動(dòng)程序210與客戶端應(yīng)用程序230之間的分離的方式。在一個(gè)實(shí)施例中，視頻捕獲API 220是微軟公司(Redmond，WA)的DirectShow。在另一實(shí)施例中，視頻捕獲API 220是用于Windows的視頻(VFW)，其也是微軟公司(Redmond，WA)的。在又一實(shí)施例中，視頻捕獲API 220是微軟公司(Redmond，WA)的實(shí)時(shí)通信(RTC)堆棧。
客戶端應(yīng)用程序230可以是使用視頻捕獲裝置110的任何程序。舉例而言，在一個(gè)實(shí)施例中，客戶端應(yīng)用程序230是即時(shí)通訊軟件(IM)。當(dāng)前可用的IM程序的一些實(shí)例是微軟公司(Redmond，WA)的MSN通訊軟件、America Online，Inc.的美國在線即時(shí)通訊軟件(AIM)和Yahoo！Inc.(Sunnyvale，CA)的Yahoo！即時(shí)通訊軟件。在另一實(shí)施例中，客戶端應(yīng)用程序230是視頻會(huì)議應(yīng)用程序，如微軟公司(Redmond，WA)的NetMeeting。在又一實(shí)施例中，客戶端應(yīng)用程序230是音頻通訊應(yīng)用程序，如Skype Group(Luxembourg)的Skype。
圖2B是說明上文參考圖2A所述的系統(tǒng)中的數(shù)據(jù)流的方框圖。
在這個(gè)圖中所說明的實(shí)施例中，視頻數(shù)據(jù)由數(shù)據(jù)捕獲裝置捕獲，傳遞給驅(qū)動(dòng)程序210，再傳遞給視頻捕獲API 220，且然后傳遞給客戶端應(yīng)用程序230。注意，如上所提及，數(shù)據(jù)流的方向可相反，即，從客戶端應(yīng)用程序230到輸出裝置(例如，連接到主機(jī)120的記錄裝置)。
可看出在用戶模式與內(nèi)核模式之間繪有區(qū)別。將參考圖3B更詳細(xì)描述這些。
圖3A是說明根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)的方框圖。其包含視頻捕獲裝置110、驅(qū)動(dòng)程序210、用戶模式視頻處理層(UMVPL)310、視頻捕獲API 220和客戶端應(yīng)用程序230。
數(shù)據(jù)捕獲裝置110、驅(qū)動(dòng)程序210、視頻捕獲API 220和客戶端應(yīng)用程序230已在上文中加以描述。通過比較圖3A和圖2A，可看出UMVPL 310是一新層。在一個(gè)實(shí)施例中，UMVPL 310插入驅(qū)動(dòng)程序210與客戶端應(yīng)用程序230之間。UMVPL 310位于數(shù)據(jù)源110與客戶端應(yīng)用程序230之間，且UMVPL 310經(jīng)配置以透明地處理數(shù)據(jù)流。這允許客戶端應(yīng)用程序230不知道來自數(shù)據(jù)源110的數(shù)據(jù)流的原始格式/內(nèi)容。因此，根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)可接受各種格式和內(nèi)容，且視用戶所需來處理并/或修改多媒體數(shù)據(jù)。
請注意，關(guān)于UMVPL 310的論述可應(yīng)用于除了視頻數(shù)據(jù)外的多媒體數(shù)據(jù)。舉例而言，用戶模式音頻處理層(UMAPL)將非常類似地起作用，只需做對于所屬領(lǐng)域技術(shù)人員而言顯而易見的修改。
在將修改音頻數(shù)據(jù)的一個(gè)實(shí)施例中，UMVPL 310可由UMAPL(用戶模式音頻處理層)替代。在另一實(shí)施例中，UMVPL 310可由UMAPL補(bǔ)充。UMVPL/UMAPL是視用戶所需修改數(shù)據(jù)流的地方。這使視頻/音頻更有吸引力且使用起來更有趣。舉例而言，UMVPL 310可執(zhí)行色彩校正、圖像變形和改變、色彩鍵控、視頻化身、界面附件(faceaccessory)、流預(yù)覽、電子欺騙或影響視頻數(shù)據(jù)流所需的任何特殊效果(例如，增加雨點(diǎn)效果)等。UMAPL可執(zhí)行(例如)通道混合、靜音緩沖、噪音抑制、噪音取消和凹口過濾、變形、形態(tài)變化、電子欺騙或影響音頻數(shù)據(jù)流所需的任何特殊效果。在一個(gè)實(shí)施例中，用戶可通過圖形用戶接口或其它接口輸入他或她對用以對多種類型的流執(zhí)行的處理類型的優(yōu)先選擇。
在一個(gè)實(shí)施例中，定義一接口以允許第三方開發(fā)用于專有處理框架的組件或插件程序。在一個(gè)實(shí)施例中，第三方實(shí)施獨(dú)立于它們將運(yùn)行的平臺(tái)。在一個(gè)實(shí)施例中，插件程序可利用UMVPL 310登記一個(gè)或一個(gè)以上的視頻和/或音頻效果。因此，UMVPL 310可用于使插件程序的概念能夠應(yīng)用于透明視頻和/或處理。
圖3B是說明根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)中的數(shù)據(jù)流的方框圖。除上文關(guān)于圖2B所論述的組件外，其包括進(jìn)程創(chuàng)建監(jiān)控器320、注入器服務(wù)330和注入器鉤子動(dòng)態(tài)鏈接庫(Injector Hook Dll)340。
如上文參考圖2B所述，視頻數(shù)據(jù)流在一個(gè)實(shí)施例中由視頻捕獲裝置110產(chǎn)生，且經(jīng)處理，且最終輸出到客戶端應(yīng)用程序230。更一般地，根據(jù)本發(fā)明的多種實(shí)施例的系統(tǒng)從源接受多媒體數(shù)據(jù)流，處理所述流，且將結(jié)果輸出到數(shù)據(jù)槽。多媒體數(shù)據(jù)源的實(shí)例包括如麥克風(fēng)、獨(dú)立視頻照相機(jī)、網(wǎng)絡(luò)照相機(jī)、嵌入視頻照相機(jī)中的麥克風(fēng)、音頻傳感器和/或其它視頻/音頻捕獲裝置之類的外圍裝置。數(shù)據(jù)也可由客戶端應(yīng)用程序230或轉(zhuǎn)換程序提供。數(shù)據(jù)流可包含文件，且從如磁帶、磁碟、閃存或智慧型驅(qū)動(dòng)器之類的便攜式存儲(chǔ)媒體，CD-ROM、DVD或其它磁性、光學(xué)、臨時(shí)計(jì)算機(jī)或半導(dǎo)體內(nèi)存提供，且經(jīng)由模擬8或16或更多的引腳端口或并行、USB、串行、防火墻(IEEE 1394)或SCSI端口接收。或者，其可經(jīng)由BluetoothTM/IR接收器所提供的無線連接、無線USB或在標(biāo)準(zhǔn)或定制計(jì)算機(jī)上提供的多種輸入/輸出接口提供。數(shù)據(jù)流可經(jīng)調(diào)度到數(shù)據(jù)槽，如文件、揚(yáng)聲器、客戶端應(yīng)用程序230或裝置(上文關(guān)于端口、存儲(chǔ)器和總線的相同論述應(yīng)用于數(shù)據(jù)槽)?？蛻舳藨?yīng)用程序230可以是使用者，它是源/數(shù)據(jù)槽110的客戶端。這可包括重放/記錄應(yīng)用程序，如微軟公司(Redmond，WA)的Windows媒體播放器(WindowsMedia Player)；通信應(yīng)用程序，如微軟公司(Redmond，WA)的Windows通訊軟件(Messenger)；音頻編輯應(yīng)用程序；視頻編輯應(yīng)用程序；或任何其它音頻或其它類型的通用或?qū)Ｓ枚嗝襟w應(yīng)用程序。上文在圖2A的內(nèi)容中已描述了客戶端應(yīng)用程序。
數(shù)據(jù)流可以是多種格式中的任一種。舉例而言，音頻流可以是PCM格式或非PCM格式、wav格式、mp3格式、壓縮或非壓縮格式、單聲道、立體聲或多通道格式，或具有給定樣本速率集合的8位、16位或24位。數(shù)據(jù)流可用模擬形式提供，且可通過模擬到數(shù)字的轉(zhuǎn)換程序，且可存儲(chǔ)在磁性媒體上或任何其它數(shù)字媒體存儲(chǔ)器上，或可包含數(shù)字信號(hào)。視頻流也可以是壓縮或非壓縮的，且可以是多種格式中的任一種，包括RGB、YUV、MJPEG、多種MPEG格式(例如，MPEG1、MPEG2、MPEG4、MPEG7等)、WMF(Windows媒體格式)、RM(實(shí)媒體)、Quicktime、沖擊波和其它格式。最后，數(shù)據(jù)也可以是AVI(視頻音頻交錯(cuò))格式。
再次參考圖3B，當(dāng)客戶端應(yīng)用程序230打開時(shí)，便在系統(tǒng)中創(chuàng)建了一進(jìn)程。進(jìn)程創(chuàng)建監(jiān)控器320監(jiān)控所創(chuàng)建的每一進(jìn)程，且只要其檢測到新進(jìn)程的創(chuàng)建便通知注入器服務(wù)330。這個(gè)注入器服務(wù)330然后將注入器鉤子的庫(注入器鉤子動(dòng)態(tài)鏈接庫340)注入到這個(gè)新的進(jìn)程中。以這種方式，可確保每一進(jìn)程被注入注入器鉤子動(dòng)態(tài)鏈接庫340。然后，這些鉤子在視頻數(shù)據(jù)到達(dá)器目的地之前經(jīng)由UMVPL 310重新路由每一視頻數(shù)據(jù)流。在一個(gè)實(shí)施例中，注入器鉤子動(dòng)態(tài)鏈接庫340使用特定組件來攔截驅(qū)動(dòng)程序210與視頻捕獲API 220之間的通信量。在一個(gè)實(shí)施例中，這些組件包括KsUser.dll、Kernel32.dll和NtDll.dll。KsUser.dll是實(shí)施Windows內(nèi)核流組件的低級(jí)別接口的共同庫，Kernel32.dll是實(shí)施大多數(shù)低級(jí)別Win32函數(shù)的共同庫，特定而言，是實(shí)施在一個(gè)實(shí)施例中攔截的CreateFile()和DeviceIoControl()函數(shù)的共同庫。NtDll.dll是用作Windows中的內(nèi)核世界的網(wǎng)關(guān)的共同庫。在一個(gè)實(shí)施例中，注入器鉤子動(dòng)態(tài)鏈接庫340攔截KsUser.dll與NtDll.dll之間和Kernel32.dll與NtDll.dll之間的調(diào)用。這是如何獲得對視頻數(shù)據(jù)的訪問和檢測對打開和關(guān)閉裝置/流的請求。
在一個(gè)實(shí)施例中，同時(shí)提供音頻和視頻數(shù)據(jù)。在所述實(shí)施例中，UMVPL 310和UMVPL兩者都存在，且視數(shù)據(jù)類型而定，經(jīng)由注入器鉤子將數(shù)據(jù)路由到UMAPL或UMVPL 310。即，訪問數(shù)據(jù)類型，且將音頻數(shù)據(jù)路由到UMAPL，且將視頻數(shù)據(jù)路由到UMVPL 310。
圖4A、4B和4C是描繪根據(jù)本發(fā)明的一實(shí)施例在一系統(tǒng)中的特定實(shí)例的流程圖，其以打開客戶端應(yīng)用程序230起動(dòng)，然后打開視頻流，再到關(guān)閉所述流。由客戶端應(yīng)用程序230、進(jìn)程創(chuàng)建監(jiān)控器320、注入器服務(wù)320和UMVPL 310以及捕獲裝置110執(zhí)行所展示的步驟。
從圖4A中可看出，當(dāng)打開客戶端應(yīng)用程序230(步驟410)時(shí)，由進(jìn)程創(chuàng)建監(jiān)控器320檢測進(jìn)程的創(chuàng)建(步驟420)。然后由注入器服務(wù)330將鉤子注入到進(jìn)程中(步驟430)。當(dāng)客戶端應(yīng)用程序230請求捕獲裝置打開視頻流(步驟435)時(shí)，UMVPL 310攔截這個(gè)請求，且然后將這個(gè)請求傳輸?shù)讲东@裝置以打開視頻流(步驟440)。捕獲裝置110打開視頻流(450)。也報(bào)告視頻流已打開(步驟455)。這個(gè)報(bào)告也被攔截(步驟457)，且由UMVPL 310執(zhí)行適當(dāng)?shù)脑O(shè)置。然后UMVPL 310像客戶端應(yīng)用程序報(bào)告打開的流(步驟460)?？蛻舳藨?yīng)用程序因此接收視頻流正被打開的報(bào)告(步驟465)。
現(xiàn)參考圖4B，可以看出客戶端應(yīng)用程序230現(xiàn)請求個(gè)別視頻幀(步驟470)。這個(gè)請求再次由UMVPL攔截(步驟475)，且然后發(fā)送到視頻捕獲裝置110。當(dāng)視頻捕獲裝置接收這個(gè)請求(步驟477)時(shí)，其發(fā)送個(gè)別視頻幀(步驟480)。這些個(gè)別視頻幀由UMVPL 310攔截(步驟485)，且由UMVPL 310處理(步驟487)。所述處理(步驟487)的實(shí)例已在上文中提供。然后將經(jīng)處理的個(gè)別幀發(fā)送到客戶端應(yīng)用程序230(步驟490)?？蛻舳藨?yīng)用程序接收這些經(jīng)處理的幀(步驟492)。
參考圖4C，可以看出客戶端應(yīng)用程序230請求捕獲裝置110來關(guān)閉視頻流(步驟492)。這個(gè)請求再次由UMVPL 310攔截且經(jīng)傳輸?shù)讲东@裝置110(步驟494)。然后由視頻捕獲裝置110關(guān)閉視頻流(步驟495)，且報(bào)告視頻流已被關(guān)閉(步驟497)。這個(gè)報(bào)告由視頻流攔截(步驟497)，且視需要執(zhí)行清除(步驟498)。最后，由UMVPL 310報(bào)告視頻流已被關(guān)閉(步驟499)，且客戶端應(yīng)用程序230接收這個(gè)報(bào)告(步驟500)。
圖5是大體識(shí)別根據(jù)本發(fā)明一實(shí)施例的一系統(tǒng)執(zhí)行的用于所創(chuàng)建的每一進(jìn)程的步驟。由進(jìn)程創(chuàng)建監(jiān)控器320檢測所創(chuàng)建的任何進(jìn)程(步驟510)。然后由注入器服務(wù)330將注入器鉤子動(dòng)態(tài)鏈接庫340注入進(jìn)程中(步驟520)。然后由UMVPL 310攔截在進(jìn)程控制下的多媒體數(shù)據(jù)(步驟530)。然后由UMVPL 310處理這些多媒體數(shù)據(jù)(步驟540)。然后將經(jīng)處理的多媒體數(shù)據(jù)提供給數(shù)據(jù)槽(步驟550)。
為了支持各種捕獲方法，在一個(gè)實(shí)施例中，需要將視頻攔截機(jī)制(攔截器)引入可能的最低級(jí)別。將必須設(shè)計(jì)用于每一捕獲方法的另外的定制攔截方法，因此大大增加了解決方案的復(fù)雜性。
為了這個(gè)原因，在一個(gè)實(shí)施例中，就在將數(shù)據(jù)發(fā)送到捕獲驅(qū)動(dòng)程序或從捕獲驅(qū)動(dòng)程序發(fā)送數(shù)據(jù)之前，在內(nèi)核邊緣攔截視頻通信量。這個(gè)用戶模式空間中的最低點(diǎn)允許監(jiān)控多種不同視頻捕獲方法。因?yàn)樗械腤DM視頻捕獲裝置使用相同的通訊協(xié)議來將數(shù)據(jù)返回給用戶模式客戶端應(yīng)用程序，所以這可起作用。
在一個(gè)實(shí)施例中，攔截機(jī)制監(jiān)控來自上述客戶端應(yīng)用程序的裝置和引腳(pin)創(chuàng)建請求；判定所創(chuàng)建的引腳中哪些是所關(guān)注的引腳；通過攔截發(fā)送到這些引腳的裝置I/O控制來監(jiān)控到這些引腳的通信量；且當(dāng)引腳關(guān)閉時(shí)停止監(jiān)控所關(guān)注的引腳。
在一個(gè)實(shí)施例中，當(dāng)監(jiān)控到一引腳的通信量時(shí)，注意力集中到創(chuàng)建格式、“設(shè)置格式請求”和讀/些請求上，這些事件的每一者對UMVPL如何處理視頻緩沖器和何時(shí)處理視頻緩沖器都有直接影響。
上述攔截機(jī)制時(shí)解決方案的第一階段。在一個(gè)實(shí)施例中，第二階段是重新創(chuàng)建UMVPL可連接的環(huán)境。在一個(gè)實(shí)施例中，建構(gòu)所述環(huán)境以優(yōu)選仿真其當(dāng)前連接的ksproxy主機(jī)，以最小化所需的對UMVPL的改變且排除對處理組件的必要改變。因此在某種程度上，這個(gè)解決方案重新創(chuàng)建了小型DirectShow層，以使得能夠重新利用用于其它應(yīng)用程序的UMVPL實(shí)施，而不需要任何顯著改變。
DirectShow(有時(shí)簡稱為DS或DShow)是由微軟產(chǎn)生的用于軟件開發(fā)的應(yīng)用程序設(shè)計(jì)接口，以利用媒體文件執(zhí)行多種操作。它是微軟的早期Windows視頻技術(shù)的替代?；谖④沇indows組件對象模塊框架，DirectShow跨越許多微軟程序設(shè)計(jì)語言提供用于媒體的共同接口，且DirectShow是可擴(kuò)展的基于過濾器的框架，其可在用戶或開發(fā)者命令時(shí)一經(jīng)請求便呈現(xiàn)或記錄媒體文件。DirectShow開發(fā)工具和文檔經(jīng)分配而作為微軟平臺(tái)SDK的部分。如Windows媒體播放器之類的應(yīng)用程序使用DirectShow或其變體來顯示文件或URL的內(nèi)容。DirectShow的最顯著的競爭是RealNetwork的Helix框架和蘋果計(jì)算機(jī)的QuickTime框架。
在一個(gè)實(shí)施例中，攔截機(jī)制導(dǎo)致小型DirectShow層來為UMVPL初始化適當(dāng)請求，以處理預(yù)期的視頻流。
攔截器將創(chuàng)建一進(jìn)程時(shí)，實(shí)際上不可能確切知道那個(gè)進(jìn)程是否將要捕獲視頻。存在確定特定進(jìn)程將很可能捕獲視頻的信號(hào)，但是不存在知道給定進(jìn)程將明確地不捕獲視頻的方式。因此，在一個(gè)實(shí)施例中，將攔截機(jī)制插入系統(tǒng)上幾乎所有的進(jìn)程中，其中異常很少。每一進(jìn)程中這個(gè)攔截機(jī)制的安裝稱為“注入碼(injecting code)”。在一個(gè)實(shí)施例中，為了解決上述問題，完整的攔截機(jī)制包含3部分1.內(nèi)核驅(qū)動(dòng)程序，其監(jiān)控系統(tǒng)中進(jìn)程創(chuàng)建，且當(dāng)創(chuàng)建了新進(jìn)程時(shí)通知客戶端服務(wù)(進(jìn)程創(chuàng)建監(jiān)控驅(qū)動(dòng)程序)。
2.系統(tǒng)服務(wù)，當(dāng)創(chuàng)建了新進(jìn)程時(shí)其接受來自內(nèi)核驅(qū)動(dòng)程序的通知，且然后在新近創(chuàng)建的進(jìn)程中起始該碼注入機(jī)制(“注入器服務(wù)”)。
3.注入器鉤子動(dòng)態(tài)鏈接庫，其表示由注入機(jī)制注入的碼。這個(gè)動(dòng)態(tài)鏈接庫(DLL)負(fù)責(zé)決定是否應(yīng)鉤住進(jìn)程，若需要?jiǎng)t將攔截鉤子安裝在進(jìn)程中，且監(jiān)控通過所安裝的鉤子的視頻通信量。那個(gè)DLL也含有小型DirectShow層，但是這個(gè)層本身不屬于攔截機(jī)制。
在這個(gè)實(shí)施例中，可支持任何用戶模式視頻捕獲方法，只要它使用ofKsUser.dll來在WDM內(nèi)核裝置上創(chuàng)建視頻捕獲引腳。所有當(dāng)前已知的視頻捕獲方法屬于這個(gè)類別。如果一些將來的視頻捕獲方法不屬于這個(gè)類別，那么將也鉤住新的版本以擴(kuò)展對這個(gè)新接口的支持。
圖6是比圖3B更詳細(xì)地展示關(guān)于注入器鉤子部分的架構(gòu)和其關(guān)系的多種組件的圖。
數(shù)據(jù)流圖7是展示根據(jù)本發(fā)明的一實(shí)施例的視頻幀的典型數(shù)據(jù)流的圖。
進(jìn)程創(chuàng)建監(jiān)控驅(qū)動(dòng)程序330負(fù)責(zé)監(jiān)控系統(tǒng)中新進(jìn)程的創(chuàng)建，且負(fù)責(zé)向客戶端系統(tǒng)服務(wù)報(bào)告所述創(chuàng)建。這個(gè)驅(qū)動(dòng)程序不是WDM驅(qū)動(dòng)程序，而是純NT驅(qū)動(dòng)程序。可將其安裝為具有SERVICE_DEMAND_START起動(dòng)類型的SERVICE_KERNEL_DRIVER。這個(gè)驅(qū)動(dòng)程序在客戶端服務(wù)起動(dòng)時(shí)將由客戶端服務(wù)起動(dòng)。
在一個(gè)實(shí)施例中，為注入器服務(wù)330和驅(qū)動(dòng)程序320通信而定義一簡單協(xié)議，其包含兩個(gè)IOCTL碼。在一個(gè)實(shí)施例中，第一個(gè)IOCTL碼僅使用包含兩個(gè)DWORD的輸出緩沖器。第一個(gè)DWORD將在完成后接收新進(jìn)程的PID，且第二個(gè)DWORD將在完成后接收進(jìn)程主線程的線程ID。它總是異步完成。在一個(gè)實(shí)施例中，第二IOCTL碼僅使用輸入緩沖器。這個(gè)輸入緩沖器包含單個(gè)DWORD，其為需要釋放的進(jìn)程的PID(見下文)。這個(gè)請求總是同步完成。
在一個(gè)實(shí)施例中，協(xié)議使用如下?？蛻舳朔?wù)將許多第一IOCTL碼排隊(duì)到驅(qū)動(dòng)程序中。所有的請求保持掛起，直到創(chuàng)建了進(jìn)程為止。驅(qū)動(dòng)程序在每次創(chuàng)建進(jìn)程時(shí)，從隊(duì)列中取出一個(gè)掛起的IOCTL(如果不存在掛起的IOCTL，那么立刻從進(jìn)程創(chuàng)建調(diào)回返同)，獲得當(dāng)前的線程id(其為進(jìn)程初始線程id)，且將PID和線程id兩者存儲(chǔ)到請求的輸出緩沖器中。然后它完成請求。之后，它仍不從進(jìn)程創(chuàng)建調(diào)回返回。它首先在堆棧上創(chuàng)建一事件，將這個(gè)事件存儲(chǔ)到由PID做索引的鏈接列表中，且等待預(yù)定時(shí)間量(例如，1秒)來完成事件。然后它將事件從鏈接列表中移除，且從調(diào)回返回。
只要第一個(gè)IOCTL碼完成，服務(wù)將采取必要的行動(dòng)來將所述碼注入到新進(jìn)程中，且其然后將發(fā)送第二IOCTL碼到驅(qū)動(dòng)程序來讓它知道它已完成了那個(gè)進(jìn)程上的工作。一旦接收到那個(gè)IOCTL，驅(qū)動(dòng)程序?qū)⒃谑录溄恿斜碇胁檎遗cPID(存儲(chǔ)在請求中)相關(guān)聯(lián)的事件，且如果驅(qū)動(dòng)程序找到對應(yīng)事件，那么驅(qū)動(dòng)程序?qū)⒂眯盘?hào)通知它，因此釋放驅(qū)動(dòng)程序在調(diào)回中的等待。然后驅(qū)動(dòng)程序完成IOCTL且返回。
上述協(xié)議允許只要新進(jìn)程起動(dòng)且給服務(wù)一個(gè)機(jī)會(huì)來在任何碼有機(jī)會(huì)進(jìn)入新進(jìn)程之前將碼注入到那個(gè)進(jìn)程中，便通知客戶端服務(wù)。這就最小化鉤子機(jī)制將在其監(jiān)控末期起動(dòng)的情況。
如下文所闡釋，在一個(gè)實(shí)施例匯總，保持掛起的所有IRP保持在取消-安全I(xiàn)RP隊(duì)列中，使得IRP可在任何時(shí)候取消，特定而言，在服務(wù)進(jìn)程終止時(shí)取消。
當(dāng)新進(jìn)程起動(dòng)時(shí)，注入器服務(wù)330接收來自內(nèi)核驅(qū)動(dòng)程序的通知，且然后它在進(jìn)行創(chuàng)建的進(jìn)程中起始碼注入機(jī)制。在一個(gè)實(shí)施例中，這個(gè)服務(wù)安裝為具有SERVICE_AUTO_START起動(dòng)類型的SERVICE_WIN32_OWN_PROCESS。在一個(gè)實(shí)施例中，這個(gè)服務(wù)僅支持開始和停止，且不支持如暫停之類的其它命令。又在一個(gè)實(shí)施例中，為了確保在啟動(dòng)進(jìn)程中足夠早地加載這個(gè)服務(wù)，使得不丟失進(jìn)程，便將這個(gè)服務(wù)加入到“AudioGroup”加載順序群組(Load Order Group)。在任何多媒體活動(dòng)可在系統(tǒng)上開始之前加載這個(gè)群組。在一個(gè)實(shí)施例中，設(shè)置服務(wù)在本地系統(tǒng)帳戶(Local SystemAccount)中運(yùn)行。
當(dāng)服務(wù)起動(dòng)時(shí)，在一個(gè)實(shí)施例中完成的第一件事是起動(dòng)內(nèi)核驅(qū)動(dòng)程序服務(wù)。在內(nèi)核驅(qū)動(dòng)程序已起動(dòng)之后，其打開又驅(qū)動(dòng)程序創(chuàng)建的裝置，且然后創(chuàng)建五個(gè)線程。每一線程將單個(gè)第一IOCTL排隊(duì)到驅(qū)動(dòng)程序中。在一個(gè)實(shí)施例中，不傳遞重疊結(jié)構(gòu)。這將使得在完成一請求之前產(chǎn)生每一線程塊。創(chuàng)建5個(gè)線程比僅創(chuàng)建一個(gè)請求其中多個(gè)重疊的請求掛起的情況更有效，因?yàn)橐粋€(gè)以上的請求可這樣同時(shí)處理。在一個(gè)實(shí)施例中，服務(wù)然后等待這些請求中的任一者完成。
如果服務(wù)需要停止，那么調(diào)用CancelIo()來取消并返回所有掛起的IOCTL請求。然后它等待所有的線程完成(在線程的句柄上等待以用信號(hào)通知)。在一個(gè)實(shí)施例中，當(dāng)線程句柄和裝置句柄完成時(shí)便關(guān)閉它們。
當(dāng)線程的請求完成時(shí)，驗(yàn)證請求的成功完成。如果未成功完成，且如果服務(wù)不停止，那么將另一IOCTL重新排隊(duì)。如果服務(wù)停止，那么替代地退出線程。在一個(gè)實(shí)施例中，mutex(相互排斥對象)用于防止服務(wù)運(yùn)行狀態(tài)在線程正在處理完成的請求時(shí)改變。另外的競態(tài)條件可發(fā)生從而導(dǎo)致線程永不終止。
如果請求成功完成，那么碼注入機(jī)制如下所闡釋來初始化，且第二IOCTL請求連同新進(jìn)程的PID發(fā)送到驅(qū)動(dòng)程序。在一個(gè)實(shí)施例中，如果碼注入失敗，那么仍然發(fā)送第二IOCTL。然后如果服務(wù)尚未進(jìn)入停止?fàn)顟B(tài)，那么服務(wù)將另一第一IOCTL請求排隊(duì)到驅(qū)動(dòng)程序中。
這里有在本發(fā)明的一個(gè)實(shí)施例中碼注入機(jī)制如何工作的闡釋1.打開具有以下訪問權(quán)限的目標(biāo)進(jìn)程PROCESS_VM_WRITE、PROCESS_VM_OPERATION、PROCESS_CREATE_THREAD、PROCESS_QUERY_INFORMATION和PROCESS_VM__READ。
2.在遠(yuǎn)程進(jìn)程中配置內(nèi)存組塊。這個(gè)組塊足夠大以含有待注入的存根碼(stubcode)。在一個(gè)實(shí)施例中，這可通過使用VirtualAllocEx()來完成。指定MEM_COMMIT和PAGE_EXECUTE_READWRITE。重要的是，將頁標(biāo)記為執(zhí)行以使它在支持NX技術(shù)的處理器上工作。
3.建構(gòu)小的存根(其將字符串的地址(用以加載的DLL的全路徑)壓入堆棧)，調(diào)用LoadLibraryA()且然后返回從堆棧彈出的四個(gè)字節(jié)(八個(gè)字節(jié)用于64為平臺(tái))。存根應(yīng)為其在遠(yuǎn)程進(jìn)程上工作而例示化。為了使這個(gè)工作，在存根末端包裝字符串，且因此字符串的地址易于基于內(nèi)存在遠(yuǎn)程進(jìn)程中所配置的地方而計(jì)算。LoadLibraryA()的地址在所有版本的Windows上這時(shí)的所有進(jìn)程中相同。這是因?yàn)镵ernel32.dll總是在進(jìn)程空間中的相同偏移處加載。這可在系統(tǒng)范圍優(yōu)化時(shí)完成以加速進(jìn)程的加載，因?yàn)樗羞M(jìn)程給出或采用所有加載Kernel32.dll中的少數(shù)。如果這將改變，那么它將易于使用PSAPI重新基于這個(gè)地址來獲得目標(biāo)進(jìn)程的Kernel32.dll基地址。因此為了在遠(yuǎn)程進(jìn)程中獲得LoadLibraryA()的地址，在當(dāng)前進(jìn)程中使用GetProcAddress()。使用GetModuleHandle()來找Kernel32.dll。
4.使用WriteProcessMemory()復(fù)制遠(yuǎn)程進(jìn)程中的存根。
5.使用CreateRemoteThread()創(chuàng)建遠(yuǎn)程進(jìn)程中的線程。那個(gè)線程應(yīng)在存根開始處起動(dòng)。
6.通過在線程句柄上等待來等待線程完成，且然后關(guān)閉線程句柄。
7.通過調(diào)用VirtualFreeEx()、傳遞MEM_RELEASE來釋放遠(yuǎn)程內(nèi)存。
8.關(guān)閉進(jìn)程句柄。
上述碼執(zhí)行遠(yuǎn)程進(jìn)程中的加載庫，因此導(dǎo)致所選的DLL(這里是注入器鉤子DLL)在遠(yuǎn)程進(jìn)程中加載。DLL的DLLMain函數(shù)從那里接管，從而將所有必要的鉤子插入遠(yuǎn)程進(jìn)程中(見下一節(jié))。當(dāng)目標(biāo)進(jìn)程消失時(shí)，所注入的DLL將自動(dòng)卸載。
在一個(gè)實(shí)施例中，如果發(fā)現(xiàn)服務(wù)不能在啟動(dòng)進(jìn)程中足夠早地加載使得不丟失所關(guān)注的任何進(jìn)程，那么服務(wù)經(jīng)修改以在五個(gè)線程已起動(dòng)之后通過枚舉所有現(xiàn)有進(jìn)程來起動(dòng)。在PSAPIAPI的情況下服務(wù)這樣做。然后服務(wù)忽略器自己的進(jìn)程和系統(tǒng)進(jìn)程，且然后繼續(xù)鉤住所有其它進(jìn)程。
注入器鉤子動(dòng)態(tài)鏈接庫340是由注入器服務(wù)在每一進(jìn)程注入的DLL。這個(gè)DLL負(fù)責(zé)決定是否應(yīng)鉤住進(jìn)程，若需要?jiǎng)t將攔截鉤子安裝在進(jìn)程中，且監(jiān)控通過所安裝的鉤子的視頻通信量。那個(gè)DLL也含有小型DirectShow層。那個(gè)DLL安裝在預(yù)定位置中，使得注入器服務(wù)可易于定位其且為其建置全路徑字符串。
在一個(gè)實(shí)施例中，這個(gè)DLL具有三個(gè)不同的部分DLLMain起動(dòng)碼，其負(fù)責(zé)決定DLL是否應(yīng)保持鉤住進(jìn)程中適當(dāng)API和進(jìn)行多種其它初始化/清除任務(wù)；小型DirectShow層碼；和API鉤子碼。
DLLMain起動(dòng)碼執(zhí)行了DLL_PROCESS_ATTACH中的大多數(shù)工作。一些額外的清除工作在DLL_THREAD_DETACH和DLL_PROCESS_DETACH中完成。在DLL_THREAD_ATTACH中不進(jìn)行工作。
在DLL_PROCESS_ATTACH中，完成下列工作1.調(diào)用GetProcessWindowStation()，其后跟隨GetUserObjectInformation()和UOI_NAME以獲得Windows Station的名稱。如果不是“WinSta0”，那么DLLMain()應(yīng)返同F(xiàn)ALSE，從而導(dǎo)致庫卸載。
2.初始化所監(jiān)控的引腳和過濾器鏈接列表。
3.在Kernel32.dll(圖6中的610)中和KsUser.dll(612)中安裝鉤子。為了獲得對兩個(gè)DLL的訪問，使用LoadLibrary()而不是GetModuleHandle()。GetModuleHandle()僅與已加載的模塊一起工作，而更重要地不保證模塊將保持加載。然后通過修補(bǔ)如下的兩個(gè)模塊的導(dǎo)入表來安裝下列鉤子。對于Kernel32.dll鉤子，修補(bǔ)ntDeviceIoControlFile()、ntCreateFile()和ntClose()。對于KsUser.dll鉤子，修補(bǔ)ntCreateFile()。這里的鉤住涉及利用具有存在于我們的注入器鉤子動(dòng)態(tài)鏈接庫中的相同原型的函數(shù)地址改變導(dǎo)入表中的這些函數(shù)的地址。這些函數(shù)將完成它們必須完成的事(見下文)，且然后調(diào)用最初在導(dǎo)入表中的原始處理程序。
4.視需要初始化任何其它內(nèi)部結(jié)構(gòu)。
5.返回TRUE。
在DLL_PROCESS_DETACH中，執(zhí)行下列工作1.清空所監(jiān)控的引腳和過濾器鏈接列表，從而處理對所有相關(guān)對象的毀壞，如我們是否已檢測ntClose()。
2.通過恢復(fù)導(dǎo)入表中的原始處理程序，并在每一有關(guān)DLL上調(diào)用一次FreeLibrary()以撤消我們先前對LoadLibrary()的調(diào)用，使所有經(jīng)鉤住的函數(shù)脫鉤(確定我們曾在DLL_PROCESS_ATTACH中成功鉤住函數(shù))。
3.視需要釋放所有其它資源。
4.返回TRUE。
小型DirectShow層如上文所說明，本解決方案的目標(biāo)是重新創(chuàng)建一與UMVPL過去所見一致的環(huán)境，以便可在無需顯著改變的情況下把UMVPL定位于所述環(huán)境中。為此，注入器鉤子DLL可創(chuàng)建三個(gè)對象(C++類)，所述對象得自若干個(gè)標(biāo)準(zhǔn)DirectShow接口。一個(gè)對象仿真一過濾器對象，另一個(gè)仿真一引腳對象，且最后一個(gè)仿真一媒體樣本。
過濾器對象得自IUnknown、IKsObject、IKsControl、IKsProperty和IBaseFilter。引腳對象得自IUnknown、IKsObject、IKsControl、IKsProperty、IPin和IMiniDShowPin。媒體樣本對象得自IUnknown和IMediaSample。
IMiniDShowPin接口是專有的。因?yàn)槠渲辉诰植渴褂?，所以其不需要IDL描述。其定義為抽象類。其包含以下方法1.HRESULT SetDataFormat(AM_MEDIA_TYPE*pAMMediaType)。這種方法記住當(dāng)前媒體格式并調(diào)用UMVPL中的IKsDataTypeHandler::KsSetMediaType()。
2.HRESULT DataReceived(KSSTREAM_HEADER*pStreamHeader)。這種方法制作一媒體樣本對象并然后調(diào)用UMVPL中的IKsDataTypeHandled::KsCompleteIoOperation()。
3.HRESULT DataSent(KSSTREAM_HEADER*pStreamHeader)。這種方法制作一媒體樣本對象并然后調(diào)用UMVPL中的IKsDataTypeHandled::KsPrepareIoOperation()。然后，其通過釋放其IMediaSample接口來毀滅所述媒體樣本。
以下是要實(shí)施的標(biāo)準(zhǔn)接口和方法的例子。
接口實(shí)施的方法IUnknownAddRef()，Release()，QueryInterface()IKsObject KsGetObjectHandle()IKsProperty Set()，Get()，QuerySupported()IKsControl KsProperty()，KsMethod()，KsEvent()IBaseFilter 不需要實(shí)施方法。
IPinQueryDirectionQ，QueryPinInfo()IMediaSampleGetPointer()，GetSize()，IsPreRoll()(總是只返回S_FALSE)，GetMediaType()，SetMediaType()，GetMediaTime()，SetMediaTime()當(dāng)創(chuàng)建了過濾器對象時(shí)，其接收對下部對象的句柄。這允許其實(shí)施其需要實(shí)施的接口。用參考計(jì)數(shù)一來創(chuàng)建所述過濾器對象。為了刪除所述對象，只要通過把所述對象投到其接口之一并調(diào)用interface->Release()從而導(dǎo)致對象參考計(jì)數(shù)到達(dá)0來釋放其接口的任一個(gè)。
當(dāng)創(chuàng)建了引腳對象時(shí)，其接收對下部對象的句柄、對下部過濾器對象的IBaseFilter的指針、當(dāng)前媒體格式(AM_MEDIA_TYPE)和引腳索引(其用于得到引腳名稱和方向(當(dāng)需要時(shí)))。這允許其實(shí)施其需要實(shí)施的接口。用參考計(jì)數(shù)一來創(chuàng)建所述引腳對象。為了刪除所述對象，只要通過把所述對象投向其接口之一并調(diào)用interface->Release()從而導(dǎo)致對象參考技術(shù)到達(dá)0來釋放其接口的任一個(gè)。當(dāng)刪除了所述對象時(shí)，其釋放在其構(gòu)造函數(shù)(constructor)中接收的IBaseFilter接口。同樣，當(dāng)創(chuàng)建了所述對象時(shí)，其通過調(diào)用CoCreateInstance且pUnkOuter設(shè)置為引腳對象的IUnknown從而請求UMVPL對象的IUnknown來與UMVPL對象聚集。記住把對于未知接口的所有QueryInterface()請求傳遞到UMVPL的IUnknown，以使聚集完全。當(dāng)毀滅了引腳對象時(shí)，釋放對已聚集的IUnknown對象的IUnknown的指針。另外，在創(chuàng)建時(shí)也查詢UMVPL的IKsDataTypeHandler接口。其用來實(shí)施IMiniDShowPin接口。在一實(shí)施例中，立刻釋放這個(gè)接口以便保持參考計(jì)數(shù)。
當(dāng)創(chuàng)建了媒體樣本對象時(shí)，其接收緩沖器地址、緩沖器大小、媒體類型和樣本媒體時(shí)間。這允許其實(shí)施其需要實(shí)施的接口。用參考計(jì)數(shù)一來創(chuàng)建所述媒體樣本對象。為了刪除所述對象，只要通過把所述對象投向其接口之一并調(diào)用interface->Release()從而導(dǎo)致對象參考計(jì)數(shù)到達(dá)0來釋放其接口的任一個(gè)。
API鉤子在一實(shí)施例中，有四個(gè)API鉤子Kernel32.dll中的ntCreateFile()、KsUser.dll中的ntCreateFile()、ntDeviceIoControlFiIe()和ntClose()。當(dāng)調(diào)用對于Kernel32.dll的ntCreateFile()鉤子時(shí)，所述調(diào)用到達(dá)標(biāo)準(zhǔn)NtDU.dll(圖6中的614)實(shí)施。如果其返回失敗，那么不再做什么。如果其成功，那么考慮OBJECT_ATTRIBUTES結(jié)構(gòu)中的RootDirectory句柄。如果其為NULL，那么考慮OBJECT_ATTRIBUTES結(jié)構(gòu)的ObjectName字段中的文件名。如果所述名稱含有對于KSCATEGORY_VIDEO或?qū)τ贙SCATEGORY_CAPTURE的GUID，那么繼續(xù)，否則不再做什么。使用返回的句柄，發(fā)送Device IOCTL以查詢對象的KSPROPERTY_TOPOLOGY_CATEGORIES性質(zhì)。如果請求失敗，那么不再需要做什么。如果其成功，那么進(jìn)行檢查，看是否KSCATEGORY_VIDEO和KSCATEGORY_CAPTURE都存在。如果不是，那么不再做什么。如果它們存在，可能所述對象是Video Capture KS過濾器對象，因此記住所述句柄以便可以監(jiān)控所述對象。在一實(shí)施例中，這是通過在小型DirectShow層中創(chuàng)建一過濾器對象來完成的。然后把這個(gè)對象投到IBaseFilter中(其中已經(jīng)有參考計(jì)數(shù)一)，把句柄和IBaseFilter接口存儲(chǔ)在一鏈接列表中(“過濾器對象鏈接列表”)。然后返回。
當(dāng)調(diào)用對于KsUser.dll的ntCreateFile()鉤子時(shí)，其用信號(hào)通知已創(chuàng)建Ks對象。在一實(shí)施例中，所述調(diào)用到達(dá)標(biāo)準(zhǔn)NtDll.dll實(shí)施。如果其返回失敗，那么不再做什么。如果其成功，那么考慮OBJECT_ATTRIBUTES結(jié)構(gòu)中的RootDirectory句柄。如果其為NULL，那么不再做什么。如果其不是NULL，那么進(jìn)行檢查，看過濾器對象鏈接列表中是否能找到所述句柄。如果不能，那么不再做什么。如果找到，那么考慮OBJECT_ATTRIBUTES結(jié)構(gòu)中的ObjectName字段。在一實(shí)施例中，這個(gè)文件名包含所有需要的信息。其結(jié)構(gòu)為GUID串繼之以二進(jìn)制結(jié)構(gòu)。如果GUID不是KSNAME_Pin，那么這不是引腳創(chuàng)建且不再做什么。另一方面，如果GUID是KSNAME_Pin，那么考慮之后的二進(jìn)制結(jié)構(gòu)。在這種情況下，其應(yīng)為KSPIN_CONNECT。如果大小錯(cuò)誤，那么不再做什么。提取KSPIN_CONNECT結(jié)構(gòu)中的引腳索引(PinId)。最后，從KSPIN_CONNECT之后的KSDATAFORMAT結(jié)構(gòu)提取創(chuàng)建格式(并存儲(chǔ)在AM_MEDIA_TYPE中)。如果大小錯(cuò)誤，那么不再做什么。這時(shí)，可得到創(chuàng)建引腳對象所需要的所有信息句柄、相應(yīng)過濾器對象的IBaseFilter(在將其交給引腳對象構(gòu)造函數(shù)前調(diào)用其上的AddRef())、引腳索引和當(dāng)前媒體格式。把這個(gè)對象投到IMiniDShowPin中(其中已經(jīng)有參考計(jì)數(shù)一)，且然后把IMiniDShowPin和引腳句柄存儲(chǔ)在一鏈接列表(“引腳對象鏈接列表”)中。如果這是引腳對象鏈接列表中的第一個(gè)對象，那么在初始化大小MAXIMUM_WAIT_OBJECTS的裝置IOCTL事件陣列(在一實(shí)施例中，所有事件都是手動(dòng)的)和有關(guān)的結(jié)構(gòu)陣列(見下文)之后起動(dòng)裝置IOCTL線程。然后返回。
當(dāng)調(diào)用ntClose()鉤子時(shí)，進(jìn)行檢查，看句柄是否在兩個(gè)鏈接列表中的任一個(gè)中。如果是，那么調(diào)用COM接口上的Release()，移除鏈接列表紀(jì)錄，且然后刪除紀(jì)錄。如果這是引腳對象鏈接列表的最后一個(gè)對象，那么停止IOCTL線程。在一實(shí)施例中，這是通過用信號(hào)通知IOCTL事件陣列的第一個(gè)事件(保留來用于終止所述線程)并在線程句柄上等待以用信號(hào)通知來完成的。然后關(guān)閉線程句柄，并且也關(guān)閉裝置IOCTL事件陣列中的所有事件。另外，也按需要釋放所有有關(guān)的結(jié)構(gòu)陣列。最后，調(diào)用NtDll.dll中的原始ntClose()實(shí)施并返回。
當(dāng)調(diào)用ntDeviceIoControlFile()鉤子時(shí)，考慮句柄。如果句柄不在引腳對象鏈接列表中，那么調(diào)用NtDll.dll中的原始實(shí)施并返回。如果句柄是所監(jiān)控引腳之一，那么進(jìn)一步考慮IOCTL請求。如果其不是設(shè)置格式請求(IOCTL_KS_READ_STREAM或IOCTL_KS_WRITE_STREAM請求)，那么調(diào)用NtDll.dll中的原始實(shí)施并返回。如果其是設(shè)置格式請求，那么調(diào)用NtDll.dll中的原始實(shí)施，且如果成功便從所述請求提取格式并調(diào)用IMiniDShowPin::SetDataFormat()來更新UMVPL和有關(guān)的COM對象中的格式。然后返回。如果其是IOCTL_KS_WRITE_STREAM請求，那么為所述請求(可能為多個(gè))中存在的標(biāo)頭的每一個(gè)調(diào)用IMiniDShowPin::DataSent()。然后調(diào)用NtDll.dll中的原始實(shí)施并返回。最后，如果其是IOCTL_KS_READ_STREAM請求，那么調(diào)用NtDll.dll中的原始實(shí)施，且如果其成功便為所述請求(可能為多個(gè))中存在的標(biāo)頭的每一個(gè)調(diào)用IMiniDShowPin::DataReceived()。然后返回。
在某些情況下，請求可為異步的。在某些情況下，(例如IOCTL_KS_WRITE_STREAM)是否在進(jìn)行請求之前完成所述處理無關(guān)緊要。然而，在其他情況下，(例如IOCTL_KS_READ_STREAM)這是重要的。在一實(shí)施例中，按以下方式解決這個(gè)問題如果在事件參數(shù)中有事件句柄，那么用特殊事件替換它(所述事件是從裝置IOCTL事件陣列分配的。如果沒有可用事件，那么對這個(gè)請求不再做什么)，且把原始事件句柄、IoStatusBlock地址、引腳句柄、操作類型(讀取流或設(shè)置格式)和所需信息的復(fù)本存儲(chǔ)在附有所述特殊事件的結(jié)構(gòu)中。然后調(diào)用NtDll.dll中的原始實(shí)施。如果事件參數(shù)中沒有事件句柄，那么按照以上所指定的同步地完成所述請求。
為使上述起作用，需要一裝置IOCTL線程。在一實(shí)施例中，按照以上所定義那樣起動(dòng)和停止所述線程。所述線程同時(shí)在裝置IOCTL事件陣列的所有事件上等待而沒有超時(shí)(timeout)。如果其是第一個(gè)事件，那么所述線程重設(shè)所述事件并退出。如果其是任何其他事件，那么首先重設(shè)所述事件。然后檢查IoStatusBlock，且如果IOCTL成功便檢查附有所述事件的數(shù)據(jù)并按照以上在同步描述中描述的那樣完成后IOCTL操作。如果IOCTL失敗，那么不進(jìn)行后操作。然后用信號(hào)通知原始事件，且把特殊事件標(biāo)記為可用于另一IOCTL。最后，所述線程回到在所有事件上等待。
應(yīng)注意，在一實(shí)施例中，每當(dāng)為了使用或刪除過濾器或引腳對象鏈接列表中包含的COM接口而查找所述列表時(shí)，用一mutex鎖定所述列表，直到完成COM接口上的操作后才將其釋放。否則COM接口在使用的同時(shí)可能被刪除，從而導(dǎo)致各種有趣的系統(tǒng)崩潰。
雖然已說明并描述本發(fā)明的特定實(shí)施例和應(yīng)用，應(yīng)理解本發(fā)明并不限于本文中所揭示的精確構(gòu)造和組件，且在不背離如以上權(quán)利要求書中定義的本發(fā)明的精神和范圍的情況下，可對本發(fā)明的方法與裝置的排列、操作和細(xì)節(jié)進(jìn)行所屬領(lǐng)域的技術(shù)人員將明了的修改、改變和變化。舉例而言，根據(jù)本發(fā)明的系統(tǒng)可用于操縱/處理靜止圖像媒體。另一個(gè)例子是在任何給定時(shí)間可存在一個(gè)以上的多媒體數(shù)據(jù)流，其中不同流包括不同類型的多媒體數(shù)據(jù)(例如音頻和視頻流)。在這種情形中，可同時(shí)使用兩個(gè)不同的處理層(例如UMAPL和UMVPL)。
權(quán)利要求
1.一種用于透明地處理多媒體數(shù)據(jù)的系統(tǒng)，包括一用于提供多媒體數(shù)據(jù)的數(shù)據(jù)源；一用于接收所述多媒體數(shù)據(jù)的數(shù)據(jù)槽；一用于檢測每一已創(chuàng)建進(jìn)程的進(jìn)程創(chuàng)建監(jiān)控器；一用于在每一檢測到的進(jìn)程注入至少一鉤子的注入服務(wù)；和一用戶模式處理層，所述至少一鉤子把所述多媒體數(shù)據(jù)重新定向到所述用戶模式處理層，且其中所述多媒體數(shù)據(jù)在其到達(dá)所述數(shù)據(jù)槽之前被透明地處理。
2.如權(quán)利要求1所述的系統(tǒng)，其中所述注入服務(wù)熱修補(bǔ)內(nèi)存中的軟件。
3.如權(quán)利要求1所述的系統(tǒng)，其中只對所述進(jìn)程的服務(wù)調(diào)用的一子集插入鉤子。
4.如權(quán)利要求1所述的系統(tǒng)，其中所述多媒體數(shù)據(jù)是視頻數(shù)據(jù)，且正好在向一捕捉驅(qū)動(dòng)程序發(fā)送所述數(shù)據(jù)或從所述捕捉驅(qū)動(dòng)程序接收所述數(shù)據(jù)之前，在內(nèi)核的邊緣攔截所述視頻數(shù)據(jù)。
5.如權(quán)利要求4所述的系統(tǒng)，其中所述視頻數(shù)據(jù)通過以下步驟被攔截監(jiān)控裝置和來自以上客戶端應(yīng)用程序的引腳創(chuàng)建請求；決定哪些已創(chuàng)建引腳是所關(guān)心的；通過攔截發(fā)送到所關(guān)心的引腳的裝置I/O控制(I/O Controls)來監(jiān)控流向這些引腳的通信量；當(dāng)所述所關(guān)心的引腳關(guān)閉時(shí)停止監(jiān)控所述引腳。
6.如權(quán)利要求5所述的系統(tǒng)，其中所述監(jiān)控流向引腳的通信量的步驟進(jìn)一步包括監(jiān)控創(chuàng)建格式、“設(shè)置格式”請求和讀/寫請求。
7.如權(quán)利要求1所述的系統(tǒng)，其中所述多媒體數(shù)據(jù)是視頻數(shù)據(jù)。
8.如權(quán)利要求2所述的系統(tǒng)，其中所述數(shù)據(jù)源是一網(wǎng)絡(luò)照相機(jī)。
9.如權(quán)利要求1所述的系統(tǒng)，其中所述多媒體數(shù)據(jù)是音頻數(shù)據(jù)。
10.如權(quán)利要求9所述的系統(tǒng)，其中所述數(shù)據(jù)源是一麥克風(fēng)。
11.如權(quán)利要求1所述的系統(tǒng)，其中所述多媒體數(shù)據(jù)是靜止圖像數(shù)據(jù)。
12.如權(quán)利要求1所述的系統(tǒng)，其中所述數(shù)據(jù)槽是一客戶端應(yīng)用程序。
13.如權(quán)利要求12所述的系統(tǒng)，其中所述客戶端應(yīng)用程序是一即時(shí)通訊應(yīng)用程序。
14.一種用于處理多媒體數(shù)據(jù)的方法，其中所述多媒體數(shù)據(jù)由一數(shù)據(jù)源提供，且所述多媒體數(shù)據(jù)由一數(shù)據(jù)槽接收，其中所述處理對于所述數(shù)據(jù)源和所述數(shù)據(jù)槽都是透明的，所述方法包括檢測一創(chuàng)建于所述系統(tǒng)中的進(jìn)程；向所述進(jìn)程中注入至少一鉤子；經(jīng)由所述至少一鉤子把受所述進(jìn)程控制的所述多媒體數(shù)據(jù)路由到一處理層；在所述處理層中處理所述經(jīng)路由的多媒體數(shù)據(jù)，向所述數(shù)據(jù)槽提供所述經(jīng)處理的多媒體數(shù)據(jù)。
15.如權(quán)利要求14所述的方法，進(jìn)一步包括只對所述進(jìn)程的服務(wù)調(diào)用的一子集插入所述鉤子。
16.如權(quán)利要求14所述的方法，其中所述注入步驟包括向內(nèi)存中的軟件提供熱修補(bǔ)。
17.如權(quán)利要求14所述的方法，其中所述多媒體數(shù)據(jù)是視頻數(shù)據(jù)，且正好在向一捕捉驅(qū)動(dòng)程序發(fā)送所述數(shù)據(jù)或從所述捕捉驅(qū)動(dòng)程序接收所述數(shù)據(jù)之前，在所述內(nèi)核的邊緣攔截所述視頻數(shù)據(jù)。
18.如權(quán)利要求17所述的方法，其中通過以下步驟來攔截所述視頻數(shù)據(jù)監(jiān)控裝置和來自以上客戶端應(yīng)用程序的引腳創(chuàng)建請求；決定哪些已創(chuàng)建引腳是所關(guān)心的；通過攔截發(fā)送到所關(guān)心的引腳的裝置I/O控制來監(jiān)控流向這些引腳的通信量；當(dāng)所述所關(guān)心的引腳關(guān)閉時(shí)停止監(jiān)控所述引腳。
19.如權(quán)利要求18所述的方法，其中所述監(jiān)控流向引腳的通信量的步驟進(jìn)一步包括監(jiān)控創(chuàng)建格式、“設(shè)置格式”請求和讀/寫請求。
20.如權(quán)利要求14所述的方法，其中所述多媒體數(shù)據(jù)是視頻數(shù)據(jù)。
21.如權(quán)利要求14所述的方法，其中所述多媒體數(shù)據(jù)是音頻數(shù)據(jù)。
22.如權(quán)利要求14所述的方法，其中所述多媒體數(shù)據(jù)是靜止圖像數(shù)據(jù)。
全文摘要
一種多媒體數(shù)據(jù)處理系統(tǒng)與方法，其透明地實(shí)時(shí)處理視頻和/或音頻流。根據(jù)本發(fā)明的一實(shí)施例的系統(tǒng)的操作不需要任何來自視頻和/或音頻流制作者或客戶端應(yīng)用程序的干涉或介入。使用這種透明解決方案，可以無縫地處理視頻和/或音頻流，且完全獨(dú)立于用戶所選擇使用的特殊客戶端應(yīng)用程序。在一實(shí)施例中，本發(fā)明使用外部服務(wù)來監(jiān)控新進(jìn)程并向這些進(jìn)程添加代碼。本發(fā)明通過熱修補(bǔ)(hot－patching)內(nèi)存中的軟件并通過只考慮選擇服務(wù)調(diào)用而插入所述系統(tǒng)中。
文檔編號(hào)G06F9/46GK1892654SQ200610087440
公開日2007年1月10日 申請日期2006年6月8日 優(yōu)先權(quán)日2005年6月8日
發(fā)明者阿諾·格拉特龍, 帕特里克·米奧托恩, 約翰·貝特曼 申請人:羅技?xì)W洲公司