視頻流的移動視頻監(jiān)控

基于視頻流的移動視頻監(jiān)控GiovanniGualdi,AndreaPrati,Member,IEEE,andRitaCucchiara,Member,IEEE摘要：移動視頻監(jiān)控代表了一個新的解決基于計算機(jī)和基于人的監(jiān)視辦法，其一方面圍繞無處不在的視頻采集，另一方面圍繞無處不在的視頻處理、觀看。為了達(dá)到這個目的，系統(tǒng)必需提供低延遲、低跳幀的高效視頻流，即使系統(tǒng)在有限帶寬網(wǎng)絡(luò)。這項研究提出了MoSES（基于移動媒體流的視頻監(jiān)控），一個對于移動視頻監(jiān)控系統(tǒng)有效的PC和掌上電腦的客戶端。它依賴H.264/AVC視頻編碼和GPES/EDGE-GPRS網(wǎng)絡(luò)。自適應(yīng)控制算法的目的就是實現(xiàn)低延遲與流暢視頻間的最佳平衡。MoSES（基于移動流的視頻監(jiān)控）為基于計算機(jī)的視頻監(jiān)控應(yīng)用提供優(yōu)質(zhì)視頻流，用于對人的區(qū)分和跟蹤。本文中提及新的通用流性能評價方法，其用于在不同的參數(shù)條件（延時、圖像質(zhì)量、視頻流暢和幀丟失）中比較MoSES與現(xiàn)有解決方案，以及在對人的區(qū)分和跟蹤方面的性能比較。關(guān)鍵詞：H.264編碼移動視頻監(jiān)控視頻流引言得益于移動設(shè)備與無線網(wǎng)絡(luò)的訪問速度，近幾年來多媒體社區(qū)的處處存在的多媒體接入（UMA）已成為共同的話題。研究中心和電信為來自世界各地的移動設(shè)備（如筆記本電腦、個人數(shù)字助理或者上一代手機(jī)）的處處存在的多媒體接入，特別是視頻，提議了新的、靈活和高效的解決方案。這樣的技術(shù)應(yīng)用可能包括消費娛樂、數(shù)字電視廣播、視頻會議、電視醫(yī)療、遙控操作、軍事應(yīng)用和遠(yuǎn)程視頻監(jiān)控，所有這些應(yīng)用都面臨著共同的技術(shù)挑戰(zhàn)。一方面，視頻無論在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量和計算資源數(shù)量方面都造成嚴(yán)重問題。另一方面移動設(shè)置和處處存在的多媒體接入需要通過不同的方式訪問，并且通常受限于無線網(wǎng)絡(luò)，即使是802.11無線局域網(wǎng)和HSPA（高速分組接入）、UMTS（通用移動通信服務(wù)）這樣的3G網(wǎng)絡(luò)，甚至是GPRS（通用分組無線業(yè)務(wù)）、EDGE-GPRS（增強(qiáng)型數(shù)據(jù)傳輸?shù)娜蜓葸M(jìn)技術(shù)）的2/2.5G網(wǎng)絡(luò)。這些沖突的要求（高數(shù)據(jù)容量和有限的資源）使高效的編解碼器不管是在下載和媒體流應(yīng)用方面的需求更加突出。在視頻數(shù)據(jù)方面，我們的目標(biāo)是讓UMA技術(shù)為個人用戶以維持足夠服務(wù)質(zhì)量。盡管如此，在一些新興應(yīng)用上，數(shù)據(jù)品質(zhì)與壓縮系數(shù)必需針對苛刻的“非人類用戶”進(jìn)行評估，也就是軟件處理和接收到的數(shù)據(jù)解釋。本文重點在于這樣的應(yīng)用，特別是移動視頻監(jiān)控：此期我們涉及廣泛的新一類實時視頻監(jiān)控應(yīng)用，此應(yīng)用案例的計算量不是在一個固定平臺負(fù)責(zé)，而攝像機(jī)直接連接該系統(tǒng)平臺。由于移動平臺的存在，移動視頻監(jiān)控所有，與視頻采集，處理，數(shù)據(jù)分析和相關(guān)的多媒體數(shù)據(jù)傳輸?shù)膯栴}變得更具挑戰(zhàn)性，無論是在發(fā)送端或者是接收端，以及無線

互聯(lián)。一詞的“移動”的含義是相當(dāng)模糊，根據(jù)上下文還可能會呈現(xiàn)不同的含義。例如，它可以不受制約留在一個固定位置安裝，或者一個移動的設(shè)置，或者一個便攜設(shè)備（比如掌上電腦和筆記本電腦），或后備電池供電設(shè)備。然而，在多媒體術(shù)語中“移動”一般涉及到連接。因此，我們假設(shè)參考移動視頻監(jiān)控系統(tǒng)是提供一個無處不在的無線連接（無論是在服務(wù)器上，客戶端或兩者都有）相反的“固定”將用于考慮與有線連接系統(tǒng)。用于移動視頻監(jiān)控體系結(jié)構(gòu)的典型例子是如圖1的三層架構(gòu)。固定攝像機(jī)移動攝像機(jī)譯碼器的視頻監(jiān)控|2pdaS?#/類固定攝像機(jī)移動攝像機(jī)譯碼器的視頻監(jiān)控|2pdaS?#/類卜人電苗第三層圖1通用移動視頻監(jiān)控體系結(jié)構(gòu)第一層（發(fā)送端或編碼器）是專門對實時數(shù)據(jù)源（攝像機(jī)）或者存儲的視頻進(jìn)行編碼的。編碼的視頻通過無線廣播頻道以盡可能廣泛的覆蓋范圍發(fā)送到第二層（接收端或解碼器）。接收到的視頻一旦解碼將在第三層處理；它可以是一個傳統(tǒng)的人性化系統(tǒng),它是由人工操作的視頻分析或者以計算機(jī)為基礎(chǔ)的移動物體自動提取和識別異常事件系統(tǒng)組成。這是不是唯一的移動視頻監(jiān)控可能的架構(gòu)智能相機(jī)的發(fā)展使更多的實時處理任務(wù)轉(zhuǎn)移到本地編碼端成為可能。在一般情況下，以計算機(jī)為基礎(chǔ)的視頻監(jiān)控算法的部分可以在第一層實現(xiàn)的，可以獲得降低傳輸帶寬和壓縮的圖像雙重好處。然而，我們的重點依然是第一層的視頻編碼和媒體流，要求的任何監(jiān)控任務(wù)的進(jìn)一步措施：這一解決方案仍然是就第三層實施監(jiān)控應(yīng)用沒有具體的設(shè)想前最靈活的。在我們的工作中，第一層將體現(xiàn)在一個標(biāo)準(zhǔn)的PC架構(gòu)，并意識到標(biāo)準(zhǔn)視頻編碼器的實現(xiàn)往往通過嵌入式硬件實現(xiàn)。雖然整體構(gòu)造，我們的重點將是最具挑戰(zhàn)的現(xiàn)場攝像，以及現(xiàn)成的視頻源的立即響應(yīng)。有許多有趣的應(yīng)用實例：在移動－固定情形：視頻監(jiān)控系統(tǒng)無線通信一個安裝在一輛城市巡邏區(qū)域的警車的攝像頭，一個裝有攝像頭的災(zāi)區(qū)監(jiān)視機(jī)器人，一個在工地每天移動的安全攝像機(jī)，這些實時的視頻流可能流向一個控制中心；反之，固定——移動的情形可能是一個警務(wù)人員在他的PDA觀看收集于安裝在一座建筑內(nèi)移動/固定的攝像機(jī)（或者來自一個安裝在移動車輛的攝像機(jī)的移動——移動情形）。在這項研究中我們提出了媒體流系統(tǒng)，叫做MoSES（基于移動媒體流的視頻監(jiān)控），有效的移動視頻監(jiān)控通用體系描述。MoSES支持不用狀況下的視頻流，針對帶寬受到限制的低延時傳輸。此外，此視頻系統(tǒng)為基于人或者基于計算機(jī)的正確分析提供足夠質(zhì)量的視頻。為達(dá)到這個目的，我們提出了一個流參數(shù)自適應(yīng)控制過程的優(yōu)化。MoSES基于開源軟件架構(gòu)。原因有兩個，第一，完整源代碼可允許任何水平的修改和優(yōu)化。第二，大部分開源軟件或者組件可以而不同的體系結(jié)構(gòu)交叉編譯和/或操作系統(tǒng)以具體的調(diào)整：MoSES客戶端意味著其不僅運行在個人電腦上，而且還運行在個人數(shù)字助理，因而夸體系結(jié)構(gòu)軟件是必需的。評估實時視頻流既不明確也不簡單。本文提出一個提供性能比較評估有效的圖像分析新方法，通過四個關(guān)鍵參數(shù)，即延時，圖像質(zhì)量，視頻流暢性和幀丟失。最后，我們對移動視頻監(jiān)控在運動體分割與追蹤方面的上述參數(shù)比較MoSES和其他媒體流系統(tǒng)所取得的成果。本文的其余部分的結(jié)構(gòu)如下:下一章節(jié)，我們定義有效的基于人和基于計算機(jī)的視頻監(jiān)控的必要條件。然后，第三節(jié)，我們回顧視頻流媒體的一些商用和科研的方法，和有關(guān)移動視頻監(jiān)控工程。第四節(jié)提出MoSES的詳情。試驗結(jié)果（第六節(jié)），第七節(jié)重點描述使用的整套方法。第七節(jié)得出結(jié)論。二、系統(tǒng)需求移動視頻監(jiān)控要求視頻直播，以保證在線觀看控制現(xiàn)場。除了這個基本特征，為了定義一個成功的移動視頻監(jiān)控系統(tǒng)還有其他要求（如表1所示）。表1系統(tǒng)要求?！岸　焙汀耙弧狈謩e代表“要求”和“不要求”#要求視頻監(jiān)控基于人基于計算機(jī)1Ubiquitousaccessibility無所不在的訪問2Lowlatency低延時3Highimagequality咼質(zhì)里圖像Preferable較好4Videofluidity視頻流暢Preferable一5Noframeskipping/loss無跳幀/丟幀一6Highframerate高幀速率一Preferable第一項要求視頻編碼充公適應(yīng)不同仍然不提供全面覆蓋的大寬帶無線網(wǎng)絡(luò)支持（例如WiFi或者UMTS/HSPA）。這項研究中選定GPRS/EDGE-GPRS網(wǎng)絡(luò)作為移動數(shù)據(jù)服務(wù)，因為它在歐洲領(lǐng)土覆蓋面廣。這僅僅是實現(xiàn)可以提供基于IP的網(wǎng)絡(luò)視頻流并不損害系統(tǒng)的通用性的選擇，鑒于可用的有效EDGEGPRS帶寬和GPRS連接,MoSES將分別在80kbps和20kbps速率下測試，另外，在移動視頻監(jiān)控的視頻信號源多種傳輸請求方面，將在20kbps和50kbps速率下模塊四臺攝像機(jī)視頻傳輸。第二項要求低延時，因為監(jiān)控系統(tǒng)應(yīng)該具有對顯示場景的變化的快速反應(yīng)。況且，移動視頻監(jiān)控系統(tǒng)要求高質(zhì)量圖像（第三項）和視頻流暢性（第四項）。兩者都符合基于人監(jiān)控的要求，和正確場景分析與視頻識別要求的可取監(jiān)控方案。這過程對噪聲、環(huán)境變化很敏感，這是因為受人工編碼和壓縮量化的影響較大。因此，可用帶寬越窄，視頻壓縮越大，越影響視頻分析的正確性。視頻監(jiān)控范圍的視頻處理最基本步驟[1]：運動物體分割，對象和對象的跟蹤分析。而最后一步在很大程度上依賴于應(yīng)用程序的目標(biāo)，分割和跟蹤任務(wù)十分普遍：在分割和跟蹤的降低了整個自動監(jiān)測系統(tǒng)性能。就靜態(tài)攝像機(jī)來說，分割的步驟通常根據(jù)背景抑制技術(shù)確定[2]，如比較實際像素值與靜態(tài)背景模型對應(yīng)點的相應(yīng)值等等。很明顯，改變像素值的幀壓縮可以顯著影響這一步驟，并使一個復(fù)雜的背景模型失效。因此，第三項至關(guān)重要。跟蹤步驟通常根據(jù)幀內(nèi)對象——跟蹤配對和采取固定幀頻的有效狀態(tài)預(yù)測的跟蹤算法確定。由此，第五項要求（無跳幀）是必需的。最后，在一個新的幀里搜索跟蹤的范圍與物體在兩個幀之間的移位成正比。因此，第六項（高幀頻）是為了防止過大搜索范圍。大多數(shù)上述需要的要求大多數(shù)UMA服務(wù)和上一代視頻流系統(tǒng)通常只是部分實現(xiàn)。另一方面，我們的MoSES系統(tǒng)專門為滿足上述要求而設(shè)計的。它基于H.264/AVC（MPEG-4第10部分）[3]-[5],通過多種改進(jìn)方法使流媒體自適應(yīng)低容量網(wǎng)絡(luò)。H.264/AVC保證更好的MPEG-2與MPEG-4圖像質(zhì)量和帶寬占用的平衡點。三、相關(guān)作品視頻流解決方案與架構(gòu)多個視頻流媒體解決方案處理步驟是視頻采集，編碼，網(wǎng)絡(luò)傳輸和視頻播放。兩個流行的現(xiàn)成方案是基于流媒體技術(shù)的MicrosoftWindowsMedia和RealNetworks[6]。此系統(tǒng)的編碼層目的是提供流媒體服務(wù)器功能等等，以處理密集型視頻廣播。他們需要強(qiáng)大的處理平臺和/或面向服務(wù)器的操作系統(tǒng)。例如，WindowsMedia流媒體服務(wù)器只能在WindowsServer操作系統(tǒng)上運行。這些專利解決方案的主要目標(biāo)是提供出于娛樂目實時和存儲視頻資源的大量大規(guī)模視頻資源訪問。因此，這些解決方案的延時相當(dāng)高（如第六節(jié)所述），這與第二項要求沖突。況且，因為典型的用戶都是非技術(shù)從業(yè)人員，往往它們主要在視頻編碼和網(wǎng)絡(luò)視頻流方面的設(shè)置相當(dāng)有限的。無論如何，其在移動視頻監(jiān)控工作的表現(xiàn)情況是不容忽視。我們測定了兩個WindowsMedia和RealNetworks的整體流性能表現(xiàn)，因為他們都提供了PC和PDA視頻播放器。數(shù)值結(jié)果將在第六節(jié)討論。Skype可能代表了最流行的音頻和視頻的免費軟件工具了多媒體流播放、音頻處理和視頻。該系統(tǒng)的整體性能非常有趣，雖然它適用于移動視頻監(jiān)控有一些不足。特別是，設(shè)置靈活性甚至比上述工具粗糙，因為幾乎一切都是自動處理。例如，抓取、幀尺寸、速度和視頻比特率不可調(diào)。這種方法使得系統(tǒng)很容易用于音頻/視頻通話，但也很死板和不夠靈活，肯定無法用于我們的目標(biāo)。另外，根據(jù)第五部分介紹的方法，延遲的測量分析在這種條件下變得不可行。Skype意思為音頻流，在視頻支持方面不能說不行，產(chǎn)生的帶寬浪費成為無線移動連接的關(guān)鍵問題。最后，Skype視頻播放器當(dāng)前只有PC版本。關(guān)于開放源碼軟件方面，VideoLAN（VLC）的客戶端可能是最知名的可用工具。不同于以往所有的例子，VLC是設(shè)計用于研究或免費使用，不作商業(yè)用途；它提供了非常靈活和完善的設(shè)置，即達(dá)到了抓取視頻細(xì)節(jié)、編碼和網(wǎng)絡(luò)流的最低水平。它支持多種視頻壓縮標(biāo)準(zhǔn)（包括H.264）和流媒體技術(shù)。但無論如何，我們的許多項目的要求使此系統(tǒng)受到強(qiáng)烈的限制。如第四節(jié)B所示，視頻延遲（必要條件2）只能保持相當(dāng)?shù)偷囊曨l質(zhì)量下降。關(guān)于帶寬使用，H.264視頻碼率控制是非常嚴(yán)格的，不允許有優(yōu)化。例如，H.264流媒體只允許在MPEGTS（傳輸流）封裝：在［7］的研究表明，這是一個缺點，因為使用MPEG-TS/UDP/IP協(xié)議的堆棧比使用P/UDP/IP協(xié)議的堆棧多兩倍多開銷。最后，VLC控制的H.264視頻參數(shù)不準(zhǔn)確，因為它可以訪問的參數(shù)的完整調(diào)色板，但卻不能正確地處理它們。人為地針對低帶寬進(jìn)行偏離標(biāo)準(zhǔn)條件優(yōu)化，將引入強(qiáng)烈的圖像質(zhì)量下降。另一種解決方案是適當(dāng)?shù)厥褂矛F(xiàn)有的組件專門針對移動視頻監(jiān)控設(shè)計和開發(fā)一個優(yōu)化的系統(tǒng)。媒體流中最復(fù)雜的區(qū)塊是視頻編碼和解碼。由于對H.264編解碼器的選擇，我們根據(jù)計算性能和參數(shù)的靈活性比較了現(xiàn)有的編碼引擎。工作性能要求必須執(zhí)行的實時編碼，相反地，如果配置了高編碼配置文件H.264要求將非常苛刻。需要靈活調(diào)整編碼器處理不同的需求，如高編碼速度，高圖像質(zhì)量。JM參考軟件，它是開源的，完全靈活和可修改的，但計算性能非常有限。相反地，英特爾集成性能基元提供一整套廣泛的數(shù)字信號處理算法，其中也包括專門的H.264視頻編碼。此庫經(jīng)過優(yōu)化，但不開源并且只能在英特爾處理器上執(zhí)行。X.264［10］是今天開源H.264編碼器之一，其在H.264標(biāo)準(zhǔn)下具有最佳性能和最高的完整性，基于這些原因它被選為圖1第一層的基礎(chǔ)塊。關(guān)于對H.264解碼器的選擇，性能問題變得非常嚴(yán)格，因為我們不僅希望標(biāo)準(zhǔn)的x86架構(gòu)上得到解決，而且CPU的有限計算能力時也能得到解決等等，如ARM架構(gòu)的PDA。同樣在JM和英特爾IPPH.264編碼器上的考慮，對他們的解碼器工具是有效的。從其他各種解碼器，有很多是開源的，如果我們只考慮那些可以在PC和PDA上編譯的解碼器，那么我們的選擇是有限的。我們基于FFMPEG選定解碼器，因其處理能力大部分的H.264編碼的能力和性能；它沒有提供一個隨時可用的PDA版本，但因為它是開源的，可以適當(dāng)修改。這個庫有額外的優(yōu)勢，即提供了許多不同的協(xié)議的網(wǎng)絡(luò)流層實現(xiàn)。移動視頻監(jiān)控流視頻監(jiān)控在過去的十年已經(jīng)達(dá)到了科學(xué)界的高峰期。就這一主題的認(rèn)真調(diào)查文件已在2000年由Lu發(fā)表。它的報告和討論信號處理的有關(guān)問題，并提出可能的解決方案。關(guān)于視頻流，研究者們從不同角度解決問題。例如，其中一個研究者使用多請求的方法解決了服務(wù)器計算資源的分配問題。另一組論文的重點是系統(tǒng)架構(gòu)，在雙方的溝通模式方面（見參考文獻(xiàn)［14］，其中的分析是基于真正的網(wǎng)絡(luò)產(chǎn)品，但不考慮低容量網(wǎng)絡(luò)）和數(shù)據(jù)同步（見參考文獻(xiàn)［15］，考慮實時車輛視頻流通信，即便基于802.11無線網(wǎng)絡(luò)，也不適合普通移動視頻監(jiān)控）。有些研究提出了低容量網(wǎng)絡(luò)系統(tǒng)視頻流系統(tǒng)，如GPRS例如，Lim等人，見參考文獻(xiàn)［16］。介紹了GPRS網(wǎng)絡(luò)的基于PDA的視頻直播系統(tǒng)。該系統(tǒng)是基于MPEG-4壓縮，并包含在PDA上實現(xiàn)的優(yōu)化算法。它可以實現(xiàn)編碼端的21fps幀速率和解碼端的29fps幀速率，并在128kbps下傳輸一個QCIF（176X144）視頻。然而，他們的系統(tǒng)在通過GPRS傳輸時，幀速度降至2-3fps。此外，系統(tǒng)延遲的信息沒有提供。參考文獻(xiàn)［17］的研究，使用跳幀解決了GPRS實時視頻傳輸?shù)膯栴}。Chuang等人，見參考文獻(xiàn)［18］通過模塊3G網(wǎng)絡(luò)處理自適應(yīng)的視頻流媒體播放：建立發(fā)送和接收過程的統(tǒng)計模型，以避免保存緩沖區(qū)下溢與播放流暢。即使研究不清楚地處理延遲測量，并且假設(shè)一個附加的定時數(shù)據(jù)交換，適應(yīng)視頻播出的想法，以優(yōu)化緩沖區(qū)管理將用于我們的研究工作中。在文獻(xiàn)中已經(jīng)設(shè)想移動視頻監(jiān)控?zé)o論是無線網(wǎng)絡(luò)標(biāo)準(zhǔn)的視頻流擴(kuò)充，沒有在遠(yuǎn)程端處理，但只有一個人遠(yuǎn)程控制操作［19］-［21］，或作為特殊情況下的分布式無線傳感器網(wǎng)絡(luò)，其中一種對應(yīng)于視頻傳感器的傳感類型［22］。此外，這些研究大多沒有解決低容量網(wǎng)絡(luò)問題。P.Mahonen在1999年發(fā)表了一個項非常有創(chuàng)意的研究。這項研究分析移動視頻監(jiān)控的關(guān)鍵問題，例如網(wǎng)絡(luò)化和數(shù)字圖像傳輸?shù)囊蟆６以僬?，與我們所做的相同，筆者評估視頻監(jiān)控最終應(yīng)用中容易出錯的傳輸和人工編碼（特別是入侵報警，目標(biāo)識別）。然而，主要是由于1999年該技術(shù)的不成熟問題。論文沒有真正提出有關(guān)視頻流在低容量移動視頻監(jiān)控網(wǎng)絡(luò)的有效建議oLam等人提出了一個很有趣的研究類似于這項工作最終目標(biāo)這一。無論如何，在他們看來，跳幀是在功能上使用幀的智能過濾以適合在低帶寬要求一一只有通過非常積極的跳幀可承受近5kbps。正如前述，這個復(fù)雜的跟蹤任務(wù)；再者，它要求移動一部分的計算到本地端的攝像頭。體系構(gòu)想MoSES的基本架構(gòu)如圖1所示。在這一節(jié)每一層將被細(xì)化。第四節(jié)A描述視頻編碼層（僅基于PC硬件開發(fā)）。解碼層設(shè)計成兩個不用的版本，根據(jù)客戶端的計算資源，即基于PC（第四節(jié)B）和基于PDA（第四節(jié)C）.計算機(jī)的視頻監(jiān)控所使用的技術(shù)是基于SAKBOT（統(tǒng)計和基于知識的目標(biāo)跟蹤）［24］，一個移動目標(biāo)檢測和跟蹤系統(tǒng)。A.視頻編碼層典型的媒體流系統(tǒng)編碼層是由三個基本塊組成（視頻采集，編碼和網(wǎng)絡(luò)媒體流）加上進(jìn)一步的控制步驟。我們的編碼器層的目的是提供在視頻源和壓縮控制的高度靈活性，并保持延遲和幀丟失率最低水平。以下體系結(jié)構(gòu)的獨特方面是實現(xiàn)這些目標(biāo)而特殊設(shè)計的。——多線程處理和管道：視頻采集，編碼和網(wǎng)絡(luò)媒體流被專用線程通過循環(huán)緩沖區(qū)解耦處理（如圖2）。經(jīng)異步線程優(yōu)化處理，每一個執(zhí)行基本上是獨立于其他的；這實現(xiàn)一個與簡單串行處理相比降低了延遲的管道。最初的X.264源代碼是為此修改的；低緩沖區(qū)占用：緩沖是必要的，以避免由于線程去耦造成視頻數(shù)據(jù)線的損失；缺點是它引入了一些延遲，并因此應(yīng)用程序被調(diào)整為保持在最低的緩沖區(qū)占用。圖2視頻編碼器功能層劃分實現(xiàn)這一目標(biāo)的最好方式是設(shè)置抓幀速率等于（或稍低于）平均編碼幀率；有第二個任務(wù)后編碼器和網(wǎng)絡(luò)流轉(zhuǎn)化器之間的緩沖區(qū)并不重要，而著重于管理和保持緩沖區(qū)始終接近零占用率?！猆DP流：原H.264編碼的流持續(xù)的傳輸給網(wǎng)絡(luò)流轉(zhuǎn)化器并打包成固定字節(jié)大小的UDP數(shù)據(jù)報。應(yīng)付網(wǎng)絡(luò)上擁塞的優(yōu)先發(fā)送，但這將付出數(shù)據(jù)報丟失的代價。盡管如此，得益于無線鏈路控制實施機(jī)制的自動重發(fā)請求，我們第六節(jié)的實驗報告將顯示通過EDGE-GPRS甚至是GPRS的傳輸是非常穩(wěn)健的，因為數(shù)據(jù)報的丟失率極低，并且接收沒有混亂。因此，事實上MoSES旨在沒有額外的音頻或文本同步下傳送視頻流，我們決定用原始的UDP代替RTP/UDP。如圖2所示，開發(fā)是基于C#、.NET框架和一定的本地C/C++組件。特別是.NET框架只在非密集型任務(wù)中使用（如GUI和控制層）。B.PC視頻解碼器基于PC的客戶端情況，解碼器的功能層劃分如圖3所示。H.264解碼需求的計算絕對低于編碼，因此，這個基于PC的層的最關(guān)鍵的問題不是優(yōu)化計算，更確切地說是高

效的網(wǎng)絡(luò)緩沖和數(shù)據(jù)流管理。事實上，即使視頻采集幀率（編碼端）和播放幀率（解碼端）被設(shè)置為相同的值，數(shù)據(jù)報的產(chǎn)生率（編碼端）和數(shù)據(jù)報的提取率（解碼端）因幾個原因隨時可能不同，比如無線網(wǎng)絡(luò)不穩(wěn)定，因操作系統(tǒng)任務(wù)而不同的CPU負(fù)載（無論是在編碼器或解碼端）等等。具體地說，下列程序采用以盡量減少延遲和保持從網(wǎng)絡(luò)下行獲得最佳視頻質(zhì)量。如圖3所示?！獎討B(tài)緩沖區(qū)大?。阂粋€足夠長的時間內(nèi)如果數(shù)據(jù)報產(chǎn)生率仍然高于數(shù)據(jù)報提取率，可能填滿緩沖區(qū)和之后收到數(shù)據(jù)報將丟失（緩沖區(qū)溢出）。我們提出了緩沖區(qū)的大小動態(tài)地適應(yīng)一個簡單的算法：當(dāng)輸入輸入超出X%時，緩沖區(qū)將為兩倍，或者當(dāng)它低于（100—X）%時減半。X值是經(jīng)驗估算且取決于網(wǎng)絡(luò)的條件，緩沖區(qū)的初始大小和視

頻比特率；視頻比特率：即使延遲時間，由于顯而易見的原因，直接關(guān)系到網(wǎng)絡(luò)緩沖區(qū)

占用，調(diào)整該系統(tǒng)以保持緩沖區(qū)盡可能空，由于緩沖區(qū)下溢將會導(dǎo)致播放幀率傾向不均

勻。因此，實現(xiàn)低延遲和良好流暢性之間的最好權(quán)衡，播放幀率控制（見圖3）一組規(guī)

則以保持緩沖區(qū)占用在T與T之間（典型值是T緩沖區(qū)的5%，T緩沖區(qū)的15%）—般LHLH說來，播放幀率在時間:上是兩個值的函數(shù)：緩沖區(qū)占用（保持在TL和TH的緩沖區(qū)大?。┖途彌_區(qū)的占用離散導(dǎo)數(shù)。自適應(yīng)控制可歸納如下：FRtj?G+p),playbackifABt〉WoccFRt-i ?\1—p),playbackFRtplaybackifABtFRtplaybackifABt〈—Wocc=SFRt-1playbackifFRt-1playback公式1^Bt,ABt'optimaloccocc(p )?1+ABt,<wocc>otherwise其中W定義為亙菇“的一個窗口（典型值是千分之幾），這代表了一個緩沖區(qū)占用可持續(xù)變化的限制，如果持續(xù)超出…，該系統(tǒng)將在很短的時間結(jié)束緩沖區(qū)溢出或下溢。P是該自適應(yīng)控制的反應(yīng)系數(shù)（0<p<l,但典型值大約百分之幾）。P越接近0,自適應(yīng)控制作用越弱；最終當(dāng)P=0時失效。 反作用隨著P增加而增加，最終以一個不穩(wěn)定的系統(tǒng)結(jié)束。二_二::的值在以下范圍最佳：T〈Bt〈TaABta0TOC\o"1-5"\h\zLoccH occ<Bt〉Ta—W<ABt<0公式2occH occBt〈Ta0<ABt<WoccL occ換句話說，當(dāng)緩沖區(qū)占用增加（或減少）的速度過快（也坯「』>許），控制將作用于播放幀率的增加（減少）。條件最佳時播放幀率保持不變。在所有其他情況下，幀速率通過一個正比于緩沖區(qū)占用變化的斜率因子略有調(diào)整。－解碼器與顯示耦合：在解碼器和顯示線程缺乏同步的情況下，將可能發(fā)生一個幀能正確在解壓但不顯示，因此失去，因為它被接下來解碼的一個幀取代（幀覆蓋效應(yīng)）。幀流緩沖將解決這個問題，但它還將引入一些延時。另一種完全避免緩沖的方法是引入一個簡單的同步解碼器－顯示，在一個該解決方案大量減少幀丟失，甚至對延遲有積極作用。幀被覆蓋前，延遲解碼器）直到幀被有效顯示。如第六節(jié)C幀被覆蓋前，延遲解碼器）直到幀被有效顯示。如第六節(jié)C所示,PDA的視頻解碼器圖4顯示了PDA解碼器的構(gòu)成。不同于PC版，由于這些設(shè)備的計算能力有限，基于PDA的解碼器的成功實現(xiàn)需要特殊的解碼器優(yōu)化。尤其，視頻解碼和網(wǎng)絡(luò)緩沖最關(guān)鍵的問題是進(jìn)程和視頻顯示之間的數(shù)據(jù)交換。在這種嚴(yán)格的條件下，最適合的操作系統(tǒng)是嵌入式Linux系統(tǒng)，提供了開源的重要優(yōu)勢，如此能夠?qū)?nèi)存、網(wǎng)絡(luò)和.進(jìn)程管理進(jìn)行低層次控制。遺憾的是，對大部分的設(shè)備和外圍設(shè)備（如GSM/GPRS調(diào)制解調(diào)器）的有限支持阻止我們采用這一解決方案，從而在WindowsCE上尋求解決方案。如下每一個組件及其最重要的功能都是為一個基于PDA的解碼器設(shè)計：一優(yōu)化的顯示控制：在基于PDA的解決方案的情況下，視頻數(shù)據(jù)直接寫入顯存比依托操作系統(tǒng)的標(biāo)準(zhǔn)函數(shù)的計算非常省力。為此，顯示控制是基于GAPI和DirectDraw，而不是GDI+函數(shù)。如需進(jìn)一步加快控制，圖像縮放和90度翻轉(zhuǎn)我們可以使用預(yù)先計算的查表；用于適應(yīng)需要播放的幀大小和方向；——進(jìn)程間通信：解碼和圖形用戶界面模塊保持完全脫離于他們的進(jìn)程（也就是它們運行在兩個獨立的進(jìn)程），使每一個處理進(jìn)程不會相互干擾（例如，當(dāng)GUI模塊調(diào)用無用單元收集程序時）如一個QQVGA視頻，24位色RGB，幀率10fps，將產(chǎn)生4.6Mbps通信帶寬，很顯然，進(jìn)程間通信（IPC）必須非常有效從而避免跳幀和保持視頻流暢。通過本地UDP環(huán)或文件系統(tǒng)的數(shù)據(jù)交換是不可行的，這兩個方法不能保持高數(shù)據(jù)傳輸速率且不損害系統(tǒng)的整體性能。此外，文件系統(tǒng)實際上是基于一個有限

數(shù)量擦寫周期的閃存，基于IPC的文件系統(tǒng)將在短期內(nèi)衰退對此的支持。影響IPC使用的最大因素是內(nèi)存映射文件（MMFs）,也就是虛擬內(nèi)存文件。這種方法允許線程間共享內(nèi)存，性能與物理內(nèi)存相媲美。自適應(yīng)播放幀率：在基于PC的解碼器所描述的自適應(yīng)控制在PDA上成功實現(xiàn)需要重新討論。由于WindowsCE不容許查詢的緩沖區(qū)占用的UDP，必需在操作系統(tǒng)的UDP緩沖區(qū)緩沖區(qū)后追加一個應(yīng)用程序的緩沖區(qū)（如圖4）。另外，在第四節(jié)B提出的算法不能成功在PDA上實現(xiàn)，由于計算資源不能維持所需的幀速率，萬一幀速度一定增加時（通常在 時發(fā)生）。為此，PDA解碼器層采用了基于保持UDP緩沖區(qū)占用盡可能低的關(guān)鍵任務(wù)輕加權(quán)控制，使得盡量減少因播放中斷引起的緩沖區(qū)下溢。給定一個值e，1的千分之幾，作為如下控制：FRtplaybackFRtpFRtplaybackFRtpFRtj -g2,playbackifABt=0公式3occifABt〉0occ日從略高于一開始，在緩沖區(qū)占用大于0的情況下反應(yīng)比其他情況下強(qiáng)。分析結(jié)果將在我們使用此參數(shù)的第六節(jié)C給出。此控制不是幀播放速率自適應(yīng)優(yōu)化算法（是為深入分析自適應(yīng)播放，參見文獻(xiàn)［18］）但我們的目的是驗證，即使在功耗處理器一個簡單的自適應(yīng)控制無需進(jìn)一步緩沖可顯著提高視頻播放的流暢性。關(guān)于緩沖區(qū)的大小和解碼器顯示耦合,PDA的解碼器解碼器實現(xiàn)在PC上所描述的同樣的程序。V?性能評價評價一個視頻流媒體直播系統(tǒng)的性能不是一個容易的任務(wù)，因為它主要基于以人類接收方式的視頻源感知。我們提出與我們的要求一致的四個方面定量測量方法。另外，如下；提出評估的移動視頻監(jiān)控系統(tǒng)性能措施。1） 圖象質(zhì)量：它可以方便地測量PSNR（峰值信號的信噪比），它給出編碼和傳輸過程引入的失真程度。即使這不完全對應(yīng)的方式我們?nèi)祟愐曈X系統(tǒng)的質(zhì)量評估，但它是一種簡單、而眾所周知的方法來衡量圖像質(zhì)量。2） 視頻延遲：沒有普遍接受的分析方法測量延時的方法。一種近似的測量可以通過同一時間服務(wù)器的編碼和解碼單元之間的同步獲得，同時，修改編碼器以加速，再加上編碼的幀，還有抓取的時間戳。然后，解碼單元檢測解壓縮幀的顯示時間扣除時間差［參見文獻(xiàn)26］。這個程序有幾個缺點：一方面為了測量得到準(zhǔn)確的時間差，必須經(jīng)常與時間服務(wù)器同步。這將既浪費CPU周期，又浪費帶寬；而且每一幀嵌入時間戳將進(jìn)一步導(dǎo)致帶寬的浪費。此外，這一類的測量需要修改的視頻采集核心函數(shù)、網(wǎng)絡(luò)和顯示，因此，它適用于開源代碼,但并不適用于例如我們需要比較的WindowsMedia和RealNetworks

非開源系統(tǒng)。因此，必須使用另一種方法測量延遲。Schmidt［見參考文獻(xiàn)27］提出了一個測量合成多媒體數(shù)據(jù)（視頻，音頻和文字）延遲的方法，即通過多個傳感器觀察媒體播放器。我修改和擴(kuò)展了實時視頻數(shù)據(jù)的方法。幀數(shù)目疊加在每一個錄制的視頻。然后，通過壓縮和流處理后，我們既在編碼單元播放，也在解碼單元播放。我們稱之為:，一個給定的時間常數(shù)，二和二'士：三分別顯示在編碼器和解碼器的幀號。我們定義時間？使 。也就是兩邊同時看到同一個幀號的時間，隱含條件是「門。我們叫土心為編碼器兩個幀的時間差，這是不變的，因為抓幀速率是常數(shù)；在這個條件下一般時間:近似為 --同時，利用延遲的定義I?三？-？，我們可以寫成：enc4decL仏t-—tencenc4decL仏t-—tencenc圖5。實驗方法測量延遲。（a）和（b）是同一個攝像機(jī)的兩幀，幀號分別為1702和1718。流會話（如圖（c））,由于延遲，當(dāng)解碼端顯示（a）時編碼端顯示的是（b）幀。這個過程需要對視頻幀嵌入幀編號然后它可以使一個工具自動識別圖像上的數(shù)字，使用普通的數(shù)字可能會產(chǎn)生問題，因為強(qiáng)烈的圖像壓縮引入失真。出于這個原因，我們傾向于采用基于代碼的數(shù)字表示。二進(jìn)制編碼的幀號疊加在每個圖像的一小部分。更具體地說，白色和黑色的色塊分別用來代碼1和0。圖5顯示了這種方法的快照。最左上角兩個色塊是靜態(tài)的，用途是用于校準(zhǔn)。視頻會話發(fā)起并且在雙方的屏幕播放的視頻編碼器和解碼器，物理位置上是相互靠近的。同時，外接高幀頻攝像機(jī)獲取并存儲在兩個屏幕上的處理的視頻流變化（如圖5（c））。得到的視頻使用簡單的圖像處理算法處理，并通過識別黑色和白色塊色塊自動計算二□和 延遲。該工具非常靈活因為它可以地非開源系統(tǒng)測量時間，也就是WindowsMedia和RealNetworks。3）幀丟失：下面的公式丟幀量化二-利用同一幀號編碼的方法：有- ， 是外部攝像機(jī)的離散采樣時間，是錄制視頻

的普通幀。LF（（的普通幀。LF（（t）顯申(j)where申（j）=J, 處FNdec（j）<1 公式（5）人FNdeCj）_1,otherwise.換句話說，已知編碼的幀速率是不變，并且外部相機(jī)幀速率比編碼和解碼的幀速率產(chǎn)高得多，如果被采集相機(jī)抓取的兩個連續(xù)幀包含相同的數(shù)字或連續(xù)數(shù)，表明沒有帆丟失。幀的損失可能是由于網(wǎng)絡(luò)數(shù)據(jù)報丟失（這最有可能引起連續(xù)數(shù)幀的丟失，由于使用高壓縮率和有限的幀大小，一個數(shù)據(jù)包通常包含多個幀）由于壓縮解碼幀跳躍或覆蓋。由于上述GPRS和EDGE，GPRS高度可靠性，在下一節(jié)我們將證明因為壓縮跳躍和解碼器幀覆蓋造成的幀丟失，這主要影響是由于網(wǎng)絡(luò)故障。4） 視頻流暢：視頻流暢可以衡量解碼器播放的兩個幀間的時間差的趨勢。這些信息可以再利用幀編碼計算。在最好的情況，-:注是常數(shù)且等于-:心，相反二注越離散，視頻播放期間丟失越多5