嵌入式多通道無線視頻傳輸?shù)拇a率自適應算法

羅際煒，瞿 濤，鄧徳祥*

（1. 武漢大學電子信息學院，武漢430079； 2. 武漢大學計算機學院，武漢430079）

（?通信作者電子郵箱ddx@whu.edu.cn）

0 引言

視頻和圖像作為人們接收信息的載體，一直是嵌入式系統(tǒng)數(shù)據(jù)采集、處理和傳輸?shù)幕A對象，所以視頻的壓縮和傳輸技術一直是人們的研究重點。同時隨著物聯(lián)網(wǎng)應用的不斷擴展，以無線網(wǎng)絡和視頻壓縮與傳輸技術為核心的嵌入式系統(tǒng)也在不斷增多。但是在無線傳輸時，網(wǎng)絡質(zhì)量和狀態(tài)會發(fā)生動態(tài)變化，在這時保證視頻壓縮和傳輸?shù)姆召|(zhì)量（Quality of Service，QoS）就成了人們必須要解決的問題。

解決該問題的方法之一就是碼率自適應。傳統(tǒng)的傳輸系統(tǒng)往往通過三個方向［1］來實現(xiàn)自適應算法:

1）網(wǎng)絡帶寬。一般是通過統(tǒng)計每個歷史視頻片段的發(fā)送時間來預估傳輸帶寬，然后根據(jù)帶寬調(diào)整視頻碼率。如文獻［2］中根據(jù)歷史片段信息構建了未來時間段內(nèi)的數(shù)據(jù)量（BWE）；文獻［3］中統(tǒng)計了大量會話數(shù)據(jù)得到了一個隱馬爾可夫模型；文獻［4］中使用視頻片段長度和其發(fā)送時間之比，等作為預估依據(jù)。這種方法的優(yōu)點是緩存上溢的概率較低，缺點是帶寬利用率低，同時未來帶寬的不確定性也為這種方法帶來了風險［5］。

2）傳輸緩存，也就是根據(jù)緩存的剩余容量來不斷調(diào)整碼率，保證緩存的使用量穩(wěn)定在某一個區(qū)間。如文獻［6］中設計了碼率和緩存使用量的特定映射關系的BBA（Buffer-Based Algorithm）；文獻［7］中基于體驗質(zhì)量（Quality of Experience，QoE）矩陣，使用Lyapunov 方法設計了一個在線控制模型；文獻［8-9］中設置了多個緩存閾值，依據(jù)當前狀態(tài)和緩存等級確定碼率。這些方法的優(yōu)點是容易保證緩存的穩(wěn)定性，但缺點是存在碼率的切換滯后和頻繁切換［10］問題。

3）兩種方法相結合，目的是同時利用兩者的優(yōu)點。比如文獻［10］中基于緩存狀態(tài)、估算帶寬和當前碼率確定馬爾可夫決策的狀態(tài)，再根據(jù)QoE參數(shù)確定獎勵函數(shù)，然后轉為最優(yōu)化問題來計算碼率調(diào)整的最優(yōu)解；文獻［11］使用探測方法得到估算帶寬，使用滑動窗口來對帶寬進行平滑處理，再根據(jù)緩存狀態(tài)來確定調(diào)度策略并得到調(diào)整碼率；文獻［12］對文獻［11］進行改進，使用緩存狀態(tài)作為平滑因子，并利用緩存和帶寬的關系確定調(diào)度策略，提高了帶寬利用率和平均視頻質(zhì)量。

但它們都是根據(jù)網(wǎng)絡狀態(tài)本身對碼率進行優(yōu)化，并且大部分都基于PC和大型移動網(wǎng)絡（如手機網(wǎng)絡）平臺，沒有針對嵌入式平臺的特點進行調(diào)整，所以在嵌入式環(huán)境中的表現(xiàn)不是很優(yōu)秀。

同時在遇到多客戶端競爭帶寬的擁塞狀態(tài)［12］時，由于傳輸控制協(xié)議（Transmission Control Protocol，TCP）的擁塞控制機制，客戶端會出現(xiàn)帶寬劇烈波動的情況。為了解決這個問題，文獻［13］中使用QoE參數(shù)構建了馬爾可夫模型，在進行狀態(tài)預測時，將用戶分成了多類，進行類內(nèi)預測。文獻［14］中先使用探測方法估算帶寬，再使用三個協(xié)同效率函數(shù)來進行流量整形（Traffic Shaping），最后利用緩存狀態(tài)計算得到閾值來調(diào)整碼率。雖然這些方法在一定程度上緩解了擁塞問題，但這些算法只會在客戶端進行統(tǒng)計和調(diào)整，沒有考慮服務器的狀態(tài)，就很難保證瓶頸狀態(tài)下多客戶端的公平、效率和穩(wěn)定性［15］。

由于嵌入式平臺經(jīng)常需要實現(xiàn)一些定制性功能，因此對于效率和穩(wěn)定性的要求更高，但也使得任務需求以及對網(wǎng)絡的收發(fā)兩端情況也更為清晰，因此可以通過嵌入式平臺的特點進行方法的改進。

本文中的嵌入式平臺有三個特點:1）實時編碼。不同于HTTP平臺（在服務器端預先將視頻編碼成不同碼率并存成多個文件），本文平臺的編碼和傳輸操作是同時進行的，這樣的優(yōu)點在于不占用空間，并且碼率的調(diào)整范圍更加精細和靈活。2）發(fā)送端和接收端是多對一的關系。文獻［1-9］中的帶寬與緩存統(tǒng)計和碼率調(diào)整都僅限于視頻接收端，這對于它們來說是合理的。因為它們的服務器往往對應了多個客戶端，并且客戶端的數(shù)量是不確定并且龐大的。而本文平臺的情況是一個接收端對應多個發(fā)送端，而且發(fā)送端的數(shù)量是有限的，所以發(fā)送和接收端都可以參與狀態(tài)統(tǒng)計和碼率調(diào)整。3）更加不穩(wěn)定的WiFi網(wǎng)絡。WiFi的信號質(zhì)量會隨著距離的遠近、墻壁的遮擋和信道繁忙程度而產(chǎn)生很大變化，進而引起帶寬的劇烈變化。但是通過一些現(xiàn)有的驅(qū)動接口可以實時獲取WiFi 狀態(tài)信息，利用這些信息可以減少網(wǎng)絡狀態(tài)變化帶來的影響。

基于上面的三個特點，本文的自適應算法在前人研究的基礎上進行改進，采用了帶寬和緩存結合的調(diào)整方法，實現(xiàn)發(fā)送和接收雙端參與的調(diào)整機制。其中發(fā)送端的帶寬估計和文獻［16］中使用MDI（McGinely Dynamic Indicator）作為估計工具不同，本文基于高斯函數(shù)對過去的網(wǎng)絡速率進行加權，從而得到了更加可信的網(wǎng)絡平均速率。發(fā)送端的緩存調(diào)整和文獻［6］中使用一種線性分段函數(shù)（BBA）不同，本文使用了分段反函數(shù)進行碼率控制，并且函數(shù)參數(shù)由估算碼率動態(tài)決定；同時還使用加權移動平均來平滑碼率，得到了更好的性能并增強了緩存的穩(wěn)定性。除此之外，本文在接收端使用了相較于文獻［17］更加簡單而有效的極大值抑制和極小值激勵的方法，保證了在瓶頸狀態(tài)下多通道傳輸?shù)墓胶头€(wěn)定性。

1 無線視頻傳輸系統(tǒng)設計

1.1 硬件環(huán)境

系統(tǒng)的核心是TMS320DM368，它的主核是具有432 MHz的ARM9，外置128 MB 的DDR2內(nèi)存，自帶有視頻壓縮功能的視頻協(xié)處理器。由于該視頻協(xié)處理器的存在，使得DM368 可以以更小的體積、成本和功耗完成其他同類芯片的視頻處理任務。芯片上運行Linux 系統(tǒng)，可以得到很多開源軟件的支持。同時芯片帶有常用的UART、SPI、I2C、USB、EMIF 等與外設的通信接口，其中的VPFE（Video Processing Front End）具有16 位寬，最高為120 MHz，可以實現(xiàn)1 080 P 30 frame/s 的原始視頻輸入和處理。

系統(tǒng)的硬件框架如圖1 所示。其中現(xiàn)場可編輯邏輯門陣列（Field Programmable Gate Array，F(xiàn)PGA）使用的是Spartan6 XC6SLX150，具有功能完善、低成本、高容量和低功耗的特點。其他的重要外設有:用于圖像采集的CMV4000 的圖像傳感器，支持最大2 048×2 048 的分辨率采集；RT3070 的WiFi 芯片，支持54 Mb/s 的802.11b 的無線網(wǎng)絡通信；128 MB 的NAND FLash 用于程序存儲，MAX1036 用于統(tǒng)計電池使用狀態(tài)。

如圖2 所示，系統(tǒng)主要由三個子模塊組成:WiFi 相機、控制單元和上位機。其中WiFi 相機和控制單元的硬件架構基本一致，只不過控制單元沒有圖像傳感器CMV4000。三個子模塊分工明確，WiFi 相機作為發(fā)送端，負責采集圖像并壓縮成H264，然后通過網(wǎng)絡發(fā)送給控制單元。其中每幀的圖像數(shù)據(jù)除了H264 碼流外，還根據(jù)控制需要添加了額外的幀頭信息，包括相機標識、幀計數(shù)、時間戳等。控制單元作為接收端，會將接收到的H264 視頻通過低電壓差分信號（Low-Voltage Differential Signal，LVDS）傳送給外設部件互連（Peripheral Component Interconnect，PCI）標準采集卡，這樣上位機就不必關心網(wǎng)絡傳輸?shù)南嚓P狀態(tài)了，所有的自適應調(diào)整都在嵌入式端完成。上位機通過PCI 采集卡得到H264 數(shù)據(jù)。該數(shù)據(jù)除了會存儲在本地的存儲設備上，還會根據(jù)幀頭信息實時解碼顯示至對應的WiFi 相機窗口上，并在該窗口顯示圖像的幀信息。

圖1 系統(tǒng)硬件框架Fig. 1 System hardware framework

圖2 系統(tǒng)設備組成Fig.2 System equipment composition

1.2 軟件數(shù)據(jù)流

CMV4000 的采集由SPI 接口控制。圖像的輸入格式為bayer 格式，需要在FPGA 上進行YUV422 轉換，然后再進入DM368 的VPFE 進 行 處 理。DM368 的H264 壓 縮 是 通 過 使 用VISA 接口調(diào)用協(xié)處理器實現(xiàn)的，在壓縮過程中不占用CPU，所以在進行壓縮的同時仍然可以進行其他處理。WiFi 相機側的數(shù)據(jù)流如圖3所示。

圖3 WiFi相機側數(shù)據(jù)流圖Fig.3 WiFi camera side data flow diagram

從線程角度講，WiFi相機側的DM368上有4個關鍵線程:VPFE 采集線程、H264壓縮線程、網(wǎng)絡發(fā)送線程和自適應算法線程。為了保證圖像數(shù)據(jù)的正確性和程序的穩(wěn)定性，這4 個線程均設置為實時線程，并且線程優(yōu)先級為VPFE＞H264＞網(wǎng)絡＞自適應算法。

控制單元側的3 個實時線程分別為網(wǎng)絡接收、負載平衡算法和EMIF 發(fā)送。其中線程優(yōu)先級為:EMIF＞網(wǎng)絡＞算法。各個實時線程間的數(shù)據(jù)均通過先進先出（First Input First Output，F(xiàn)IFO）隊列進行傳遞，以保證線程之間不相互依賴和干擾，并且實現(xiàn)資源互斥和數(shù)據(jù)同步。在啟動時，系統(tǒng)會將所有的FIFO 隊列清空并初始化，然后按照優(yōu)先級大小的順序創(chuàng)建線程。

圖4 控制單元側數(shù)據(jù)流圖Fig.4 Control unit side data flow diagram

1.3 碼率調(diào)整與網(wǎng)絡傳輸

DM368 的碼率改變是通過VISA（Virtual Instrument Software Architecture）接口實現(xiàn)的。VISA 接口可以實時指定單位為Kb/s 的碼率壓縮，但壓縮后的得到的輸出碼率不會完全準確。碼率壓縮只是盡量以指定碼率為目標，會有一定的上下浮動。因為浮動的范圍是有限的，所以本文在實際調(diào)整碼率時會留有一定余量（一般為20%）。

網(wǎng)絡傳輸使用TCP，接口為標準socket。由于是無線網(wǎng)絡，本文可以通過WiFi 芯片的驅(qū)動接口獲取網(wǎng)絡狀態(tài)信息。如WiFi 相機側可以通過IOCTL 接口獲取連接質(zhì)量，控制單元可以通過驅(qū)動獲取網(wǎng)絡負載、丟包率、信道狀態(tài)等信息。這些信息都可以作為自適應算法中網(wǎng)絡帶寬的評價標準。

網(wǎng)絡傳輸?shù)臄?shù)據(jù)分為視頻數(shù)據(jù)和心跳控制指令，兩種數(shù)據(jù)分別在不同的TCP通道中傳輸。其中心跳控制主要有三個作用:1）在心跳正常連接后，發(fā)送交互指令用于建立視頻通道鏈接（類似于FTP協(xié)議）；2）檢測相機和控制單元的連接狀態(tài)，在超時后主動斷開；3）控制單元主動向WiFi 相機發(fā)送抑制指令。在接收到抑制指令后，WiFi 相機會根據(jù)指令信息調(diào)整壓縮碼率。

2 碼率自適應算法

本文自適應算法的假設有兩個:1）相機端視頻采集的幀率是固定的，所以每一幀的壓縮數(shù)據(jù)都會準時送到網(wǎng)絡的發(fā)送緩存中；2）控制單元對于接收到的壓縮圖像的處理是瞬時的，不會出現(xiàn)接收的到圖像處理不過來的情況。這樣對于緩存，本文只需要考慮相機端的狀態(tài)就可以了，對于相機端來說，緩存中數(shù)據(jù)過多意味著發(fā)送不過來了，需要降低碼率。緩存中數(shù)據(jù)過少，會導致緩存出現(xiàn)下溢，降低帶寬利用率并造成卡頓，需要提高碼率。

本文的碼率自適應算法的最終目標是保證緩存穩(wěn)定、碼率平滑調(diào)整、獲得最好的QoS。本文的帶寬估計、緩存算法和碼率改變都是在相機端進行的。控制單元所做的就是從心跳包中獲取所有相機的當前碼率，同時通過心跳包發(fā)送控制信號影響相機端的調(diào)整碼率，以保證每個相機公平地競爭帶寬。

2.1 基于網(wǎng)絡狀態(tài)的帶寬估計方法

為了估計當前的網(wǎng)絡帶寬，本文首先會統(tǒng)計過去一段時間內(nèi)的網(wǎng)絡速率。為了方便統(tǒng)計，系統(tǒng)的數(shù)據(jù)發(fā)送機制為分包發(fā)送。每一包限制最大長度為N（當前為16 KB），當一幀視頻數(shù)據(jù)長度小于等于N時，則將該幀當作一包發(fā)送；如果幀長度大于N，則分成多包發(fā)送。這樣假設當前有一包數(shù)據(jù)并且長度為n，本文會在發(fā)送前和發(fā)送完成時分別獲取時間戳tstart和tend，所以瞬時發(fā)送速率sinstant的計算如式（1）所示:

但是在實際測試中這個瞬時速率的波動會很大:一方面，這個瞬時速率是不可信的，因為這個速率會被很多因素所影響，如信道被占用、TCP 丟包重發(fā)等；另一方面，波動很大的瞬時速率也是不可用的，因為不斷波動的速率會導致碼率頻繁并劇烈地調(diào)整，影響算法的QoS。所以為了把速率波動控制在一定范圍內(nèi)，本文采用基于瞬時速率的一種平均速率，同時為了保證速率的可信性，在計算平均時速時會加上權重。本文認為越接近當前時間的瞬時速率越具參考性，分配的權重應該更大，所以使用了高斯函數(shù)來計算權重。相對于馬爾可夫模型，使用高斯函數(shù)加權相當于進行了一次高斯濾波，能增加預測結果的平滑性從而提高穩(wěn)定性。平均速率saver的計算如式（2）所示:

其中:可調(diào)節(jié)的參數(shù)有N 和c，N 決定了使用過去多少個數(shù)據(jù)包的瞬時速率，c 決定了高斯曲線的胖瘦程度，也就是對最近瞬時速率的關心程度。本文實驗時設定的N和c為100和12。根據(jù)saver就可以通過式（3）得到依據(jù)帶寬估算得到的碼率rband:

其中:a是2.3節(jié)提到的余量。

WiFi 連接質(zhì)量也可以作為帶寬估算的一個參考。在信號質(zhì)量不斷變化過程中，通過信號強度信息，可以得到當前帶寬的一個較為可靠的上限。信號強度被分為1～10個等級，本文使用開源工具iPerf 對每個等級下的平均帶寬進行實際測試和統(tǒng)計，得到對應的WiFi 模塊吞吐量等級表。這個吞吐量將作為帶寬估算的saver的上限smax。

表1 WiFi模塊吞吐量等級Tab. 1 WiFi module throughput rank

在控制單元可以通過心跳包獲取每個已連接相機的已用帶寬。為了保證相機帶寬的公平競爭，控制單元會定期向占用帶寬最大的相機發(fā)送抑制信號，向占用帶寬最小的相機發(fā)送激勵信號。同時如果有新的相機接入控制單元，單元會向所有其他相機發(fā)送抑制信號，以保證新來的相機可以獲得足夠的帶寬。相機接收到抑制信號會降低帶寬估算時速率的標準，接收到激勵信號則會嘗試增加估算帶寬。

2.2 結合緩存狀態(tài)的碼率平滑方法

如果每次估算出來的帶寬都恰好正確，并且輸出碼率也符合理想值，那就不擔心關心緩存問題了。因為每幀視頻都會按計劃產(chǎn)生并發(fā)送完成，緩存中的數(shù)據(jù)就不會增加或減少。但不管是碼率還是帶寬都不可能準確地控制和估計，實際的輸出碼率會在指定參數(shù)的一定范圍內(nèi)上下浮動，帶寬也會因為復雜的網(wǎng)絡環(huán)境而變得不符合預期。如果僅僅使用帶寬估計的方法，那么必然會出現(xiàn)緩存的上溢（導致丟幀）或下溢（導致卡頓），從而影響方法的QoS 指標，所以結合緩存狀態(tài)來調(diào)整碼率是必要的。

根據(jù)圖5 可知碼率自適應的目標是維持緩存中的數(shù)據(jù)量維持在dt附近。總緩存量為dmax，本文實驗中設定為8 MB。dt并不是一個定值，因為本文為了保證視頻幀率的穩(wěn)定性，將視頻傳輸延時T 設置為500 ms。所以在碼率為4 Mb/s 的情況下，緩存量dt應約為256 KB。但在實際運行過程中碼率是動態(tài)變化的，根據(jù)時延和碼率得到的dt也會不斷變化，所以dt的計算公式如下:

其中:ri-1是本次調(diào)整前的碼率。在緩存低于dt時，說明傳輸快了，應該增大碼率來獲得更高的帶寬利用率，同時防止視頻傳輸幀率升高而導致緩存下溢；緩存高于dt，說明傳輸慢了，應該降低碼率，以防止傳輸幀率降低導致緩存上溢。這是基于緩存的碼率調(diào)整策略，為了實現(xiàn)這樣的效果，本文使用了一個簡單的分段函數(shù)，如式（5）所示:

其中:x 為當前緩存的余量；rband為根據(jù)帶寬估算方法計算出來的當前碼率；ri′就是調(diào)整之后的碼率。本文會為碼率分別設置一個上限r(nóng)max和下限r(nóng)min，以防止碼率無限制地上升或下降。如果在實現(xiàn)中直接使用式（5）會出現(xiàn)碼率驟降或驟升的問題，而碼率的急劇變化會影響用戶的觀看體驗，進而降低QoS 的評價。產(chǎn)生這個問題的原因之一在于:在通過式（5）得到新的碼率后，新的碼率會進而影響dt。假設x ＞dt，則計算出的ri會小于ri-1，根據(jù)式（3）可知dt也會變小。在x 變化不大的情況下，根據(jù)式（4）在計算ri+1時就會因此而被縮小，所以這種縮小會隨著一次次新的碼率調(diào)整而不斷傳遞，最終導致碼率迅速下降。當x ＜dt時，同理碼率會被放大。

圖5 緩存量和碼率的關系Fig.5 Relationship between buffer size and rate

所以為了減少這種影響，實現(xiàn)碼率的平滑調(diào)整，也就是把碼率的變化幅度控制在指定范圍內(nèi)，本文將ri-1也作為碼率調(diào)整的一個參考:

其中:1- p 為ri-1的權重，決定了碼率的最大變化幅度，本文實驗中設定p 為0.4；b 是3.1 節(jié)提到的控制單元傳來的碼率調(diào)整信號，b ＞1 則為激勵信號，b ＜1 則為抑制信號，默認b= 1；ri即為調(diào)整后的碼率。

2.3 算法流程

控制碼率調(diào)整的頻率是必要的，因為碼率調(diào)整頻率過高或過低都會引入新的問題。每一次頻率調(diào)整都會引入一個新的I 幀，所以頻率過高會導致I 幀占比增加，導致數(shù)據(jù)量增大，降低碼率調(diào)整的準確性。調(diào)整頻率過低會導致碼率的驟增或驟降，同時也容易使視頻幀率發(fā)生抖動。所以在實際調(diào)整過程中，最合適的調(diào)整時機是在程序的下一幀就是I 幀時。系統(tǒng)當前設置的I幀間隔為30幀，因此碼率調(diào)整的間隔Rinterval=30最為合適。

WiFi相機側的算法的流程如下:

1）設置當前碼率ri為R（默認碼率，本文實驗中設定值為4 Mb/s）。

2）在新的一包發(fā)送完成后，按照式（1）統(tǒng)計當前包的瞬時速率si。

3）如果當前包計數(shù)為小于N 或者當前幀的下一幀不是I幀，則返回步驟2）。

4）以歷史瞬時速率si-N+1到si為窗口，按照式（2）計算當前的平均速率saver。

5）如果saver＞smax，則saver= smax，并按照式（3）計算帶寬估算碼率rband。

6）統(tǒng)計當前緩存的用量x，并根據(jù)式（4）～（5）計算緩存調(diào)整碼率ri′。

7）檢查控制單元心跳包中的碼率調(diào)整信號b，并根據(jù)式（6）計算得到平滑后的碼率ri。

8）將ri設為當前碼率，返回步驟2）。

如圖6 所示，控制單元的碼率控制流程分為兩個循環(huán)，T1和T2分別是兩個循環(huán)的時間窗口大小。其中的抑制和激勵信號是通過網(wǎng)絡心跳包進行傳遞，信號的大小是可以預設的參數(shù)，該信號將會影響相機的下一次碼率調(diào)整。第一個循環(huán)控制T1用于為新相機快速空出可用帶寬，減小新相機加入時對網(wǎng)絡產(chǎn)生的影響，實現(xiàn)新相機的快啟動，保證網(wǎng)絡穩(wěn)定性；第二個循環(huán)T2用于平均碼率，防止出現(xiàn)單一相機占用大量帶寬，而某些相機卻得不到帶寬的情況，保證網(wǎng)絡的公平性。

圖6 控制單元的碼率控制流程Fig.6 Control unit rate control flowchart

3 實驗與結果分析

3.1 評價指標

本文的自適應算法分為三個部分，每個部分都有自己的作用和目標:帶寬估計算法是為了準確估計當前帶寬，根據(jù)帶寬來得到一個基礎碼率；緩存狀態(tài)算法是為了控制緩存的上下浮動，減少碼率調(diào)整和帶寬的不準確性帶來的影響；平滑方法是為了防止碼率出現(xiàn)驟升或驟降。這些方法的性能需要一些指標來進行評價。

評價視頻傳輸質(zhì)量的指標有很多，但提高這些指標，往往要求算法參數(shù)向相反的方向調(diào)整，所以本文需要在這些指標之間作出權衡。參考文獻［18］，本文使用QoS 指標作為視頻傳輸質(zhì)量的評價標準。QoS 是一種用來解決網(wǎng)絡延時和阻塞的技術，它的評價指標則是一個通用的用于評價傳輸質(zhì)量的標準。QoS主要有以下五個關鍵指標:

1）吞吐量/帶寬利用率。

從WiFi 相機的角度講，本文的目標是提高每個相機的吞吐量；從控制單元的角度講，本文的目標是提高帶寬的利用率。通過統(tǒng)計相機每次發(fā)送的數(shù)據(jù)數(shù)量di即可得到相機吞吐量ti:

其中:T為統(tǒng)計的時間窗口大小。

影響吞吐量的主要因素是緩存下溢。正常情況下，緩存中都應該是有數(shù)據(jù)的，但如果碼率估計不足，會導致發(fā)送比緩存增長快，然后緩存下溢，造成某次發(fā)送時沒有取到數(shù)據(jù)。

在控制單元統(tǒng)計每個相機的吞吐量，吞吐量的總和與帶寬B之比就是帶寬利用率bu:

2）時延。

時延是指相機從拍攝到上位機顯示一幀圖像之間所產(chǎn)生的時間差。而在本文中能夠控制的時延是WiFi 相機產(chǎn)生一幀壓縮數(shù)據(jù)，到控制單元接收到一幀數(shù)據(jù)的時間差。本文會在兩個地方分別打上時間戳，所以時延的計算方法如下:

影響時延的主要因素是緩存中的數(shù)據(jù)量，緩存中的視頻幀數(shù)越多，則時延越大。但本文傾向于在緩存中保留一定的幀數(shù)，這樣可以防止緩存出現(xiàn)下溢而導致時延抖動。

3）丟幀率。

導致丟幀的根本原因是緩存上溢。丟幀是很嚴重的問題，視頻一旦丟幀，意味著到下一個I 幀到來之前，視頻都會不正常，所以在任何情況下都應該避免丟幀。本文通過幀計數(shù)的跳變fcount來統(tǒng)計丟幀率，每分鐘內(nèi)的跳變次數(shù)即為丟幀率plose:

其中:T為統(tǒng)計的時間窗口大小。

4）抖動。

緩存中的數(shù)據(jù)量驟增或驟減都會導致抖動，這里的抖動是指時延抖動。本文通過統(tǒng)計每幀的時延ti計算一段時間窗口內(nèi)的時延標準差vt來評價抖動指標，其中N 為統(tǒng)計的幀窗口大小，-t為窗口內(nèi)的時延均值:

同時本文還會統(tǒng)計緩存中數(shù)據(jù)量的標準差di來側面評價抖動指標:

其中:T為統(tǒng)計的時間窗口大小；-d為窗口內(nèi)的數(shù)據(jù)量均值。5）平滑性。碼率的頻繁切換或者劇烈波動都會導致用戶的觀看體驗下降［19］，所以碼率調(diào)整的平滑性也是評價算法可用性的重要指標。假設ri是某次調(diào)整后的碼率，那么碼率的平滑指標vsmooth（數(shù)值越小越平滑）可以這樣計算:

3.2 結果分析

本文為自定義的嵌入式實驗平臺，一個控制單元對應多個相機，拓撲結構如圖2 所示。網(wǎng)絡配置為802.11g（使用iperf 工具測試，狀態(tài)良好的情況下，無線網(wǎng)絡的平均速率為17 Mb/s，峰值速率為22 Mb/s，本文將此峰值速率作為帶寬上限）。控制單元作為熱點，相機啟動時自動連接。控制單元為視頻唯一接收端，相機為視頻發(fā)送端，采用TCP，視頻幀格式為自定義幀頭+H264幀數(shù)據(jù)，其中幀頭的數(shù)據(jù)量可忽略。

為了保證實驗質(zhì)量，本文的實驗在室外進行。相機對街道場景進行拍攝，產(chǎn)生分辨率為1 080 P 的30 frame/s 的H264視頻流。設置視頻碼率上限為12 Mb/s，下限為2 Mb/s。控制單元接收到的視頻流會轉發(fā)至上位機。上位機可以解析視頻的幀頭信息來獲得如時間戳、長度、相機id 等信息，從這些信息可以統(tǒng)計出QoS指標；同時在上位機也可以實時觀看視頻，評價視頻質(zhì)量。

為了控制變量，本文將分別實驗五種情況（時間均為3 min）:

1）單相機拍攝，模擬在沒有瓶頸下的拍攝（1S）。

2）單相機拍攝，拉遠拉近距離時的情況，模擬信號質(zhì)量動態(tài)變化（2S）。

3）多相機拍攝，相機數(shù)量逐漸增加，模擬相機遇到瓶頸時和有新相機加入（3S）。

4）多相機拍攝，相機數(shù)量固定為最大值4，模擬多相機競爭帶寬（4S）。

5）多相機拍攝，拉遠拉近距離時的情況，模擬信號質(zhì)量動態(tài)變化（5S）。

在這幾種情況下分別統(tǒng)計QoS的五個指標。

3.2.1 帶寬估計

為了控制變量，本文將分別對兩個算法模塊進行替換，然后進行性能評估。其中帶寬估計模塊分別用MDI［16］、使用最后的歷史片段速率作為預估帶寬IB（Instant Bandwidth）、使用最后的N 個歷史片段的平均速率作為預估帶寬MB（Mean Bandwidth）和本文加了高斯權重的平均速率的GB（Gauss Bandwidth）進行性能比較。其中參數(shù)N 設為100，c 設為12（參考3.1節(jié)）。

由圖7的情況2S可知相機吞吐量會隨信號質(zhì)量的變化而變化，由情況3S 可知吞吐量也會受到其他相機接入的影響。由圖8 可知情況1S 下相機吞吐量還沒有達到帶寬瓶頸，估算出來的帶寬超過了碼率上限。所以在碼率保持最大的情況下，四個方法的平均吞吐量相差不大。情況2S、3S、4S和5S中遇到了帶寬瓶頸。在這種情況下，吞吐量的大小和緩存下溢的時間有關，而緩存的穩(wěn)定性取決于帶寬估計的準確性。在這四種情況下，GB 方法的吞吐量都高于其他方法，證明了GB方法帶寬估計的準確性較高。

如圖9 所示，本文統(tǒng)計碼率變化圖時，是按照每3 s 得到一次當前的調(diào)整碼率，而不是3 s時間段內(nèi)的平均碼率。其中本文的GB方法相比其他兩種，碼率的波動明顯較小。同時根據(jù)表2 可知，平滑性會受到信號狀態(tài)變化和帶寬競爭而變差，而在這幾種情況下GB 的碼率平滑性都顯著小于其他三種方法，可以提供更好的視頻質(zhì)量。這說明帶寬的估計的準確性會影響碼率調(diào)整的平滑性，準確的帶寬估計可以增加緩存的穩(wěn)定性。

圖7 GB的吞吐量隨時間的變化Fig.7 GB throughput changing with time

圖8 各帶寬估計方法的吞吐量直方圖Fig.8 Throughput histogram of each bandwidth estimation method

圖9 各帶寬估計方法碼率時間變化（情況4S下）Fig.9 Rate changing with time of each bandwidth estimation method（situation 4S）

表2 各帶寬估計方法的平滑性統(tǒng)計Tab. 2 Smoothness statistics of each bandwidth estimation method

3.2.2 緩存模塊

緩存模塊將用禁用緩存模塊DB（Disable Buffer）、緩存的分段線性函數(shù)BBA［6］和本文的緩存的分段反比例函數(shù)SFB（Segmentation inverse Function Buffer）進行性能比較。

本文中的BBA 因為針對的是相機端（發(fā)送端）的緩存，緩存和碼率的映射變化和接收端的情況正相反，所以BBA 的映射關系如圖10 所示，其中參數(shù)rmax為12 Mb/s，rmin為2 Mb/s，b1為32 KB，bm為4 MB，bmax為8 MB。

如圖11所示，SFB方法的碼率調(diào)整更加平穩(wěn)。DB因為沒有緩存調(diào)整，只能根據(jù)估算的帶寬來調(diào)整碼率，但由于TCP機制存在著短期和長期的波動，還有估算的不確定性，導致其碼率波動很大。根據(jù)表3可知，SFB碼率調(diào)整的平滑性在幾種情況下都好于其他方法，同時在吞吐量上也有顯著優(yōu)勢（見圖12）。

圖10 本平臺下的BBA的緩存和碼率映射圖Fig.10 BBA buffer and rate mapping diagram on the proposed platform

圖11 各緩存模塊方法碼率時間變化（情況2S）Fig.11 Rate changing of each buffer method（situation 2S）

圖12 各緩存模塊方法的吞吐量統(tǒng)計Fig.12 Throughput histogram of each buffer method

表3 各緩存模塊方法的平滑性統(tǒng)計Tab. 3 Smoothness statistics of each buffer method

如圖13 所示，本文統(tǒng)計緩存變化圖時，是按照每3 min 得到一次當前緩存的數(shù)據(jù)量，而不是3 min時間段內(nèi)的緩存平均數(shù)據(jù)量。其中可以看到DB 的緩存量比較低，且經(jīng)常緩存下溢，造成吞吐量下降。根據(jù)表4～5 可知，SFB 緩存量稍高，但波動較小，可以減少緩存和時延抖動，同時保持較高的吞吐量，得到更好的QoS。BBA 的波動最大，同時存在緩存下溢和上溢（丟幀，見表6）的情況，所以雖然吞吐量比DB 大，總體QoS并不算好。

圖13 緩存數(shù)據(jù)量時間變化（情況5S）Fig.13 Buffered data scale changing with time of each method（situation 5S）

表4 緩存抖動統(tǒng)計表 單位：KB Tab. 4 Buffer jitter statistics unit:KB

表5 平均時延/時延抖動統(tǒng)計 單位：ms Tab. 5 Average delay/delay jitter statistics unit:ms

表6 丟幀率統(tǒng)計（平均每分鐘的丟幀數(shù)量）Tab.6 Frame loss rate statistics（dropped frames per minute）

3.2.3 控制單元

控制單元將分別啟用（EC）和禁用（DC）碼率控制模塊進行測試，并根據(jù)測試結果來分析接收端的碼率控制對性能是否有影響。其中EC 的抑制信號參數(shù)設為0.9，激勵信號參數(shù)為1.1。

EC 中由于加入了舊相機抑制、新相機激勵的方法，實現(xiàn)了相機的“快啟動”。新相機在建立連接后，可以更快地獲得基礎帶寬，并且迅速穩(wěn)定下來。其中EC的平均“啟動”時間約為4 s，DC 則至少需要10 s，并且DC 的帶寬本身就難以穩(wěn)定下來。

由圖14～15 可知，在控制單元的碼率控制模塊的作用下，EC 的4 個相機占用帶寬比較穩(wěn)定，相機能夠更加公平地競爭帶寬。而DC 由于沒有進行控制，出現(xiàn)了帶寬分配不公，某些相機占用了大量帶寬，其他相機卻得不到足夠帶寬的情況。同時可以看到圖15 中DC 的每個相機的帶寬波動劇烈，這是因為相機端算法的調(diào)整會造成吞吐量和碼率的頻繁波動。這就證明了在多通道情況下控制單元端的碼率控制模塊的有效性和必要性。

圖14 帶寬利用率折線堆積圖（EC，4S情況）Fig.14 Bandwidth utilization stacked line chart（EC，in 4S）

圖15 帶寬利用率折線堆積圖（DC，4S情況）Fig.15 Bandwidth utilization stacked line chart（DC，in 4S）

表7 帶寬利用率統(tǒng)計 單位：%Tab.7 Bandwidth utilization statistics unit:%

4 結語

本文在相機端設計了一個結合帶寬估計和緩存狀態(tài)的碼率自適應算法。其中帶寬估計使用高斯函數(shù)對歷史速率進行加權，得到較為可信的估算帶寬；緩存狀態(tài)使用分段反比例函數(shù)（函數(shù)參數(shù)由估算碼率動態(tài)決定），得到了一個緩存和碼率的映射關系，同時利用加權移動平均法對碼率進行平滑；控制單元端加入了多相機碼率控制的方法，從接收端對碼率進行調(diào)整。實驗結果表明:在本文的嵌入式環(huán)境下，相對于MDI的帶寬估計方法，本文所使用的GB 方法能更好地估計帶寬，不但能達到更高的吞吐量碼率也更加地平滑；而對于緩存模塊部分，本文也在提出了SFB的方法，緩存和時延抖動都比BBA方法更小。由于在這兩個方向都進行了優(yōu)化，本文算法的QoS 提升更加明顯，緩存的穩(wěn)定性更強，碼率的平滑性和帶寬利用率也更高。同時在新相機加入時實現(xiàn)了快啟動，在多相機競爭帶寬的情況下，也實現(xiàn)了帶寬的公平性和穩(wěn)定性。

對于算法的應用范圍而言，本文的GB帶寬估計方法在不同應用下的網(wǎng)絡發(fā)送端都能夠得到更加平滑且準確的估計效果，而SFB部分雖能得到更加平穩(wěn)優(yōu)越的性能，但由于緩存量較高，在復雜網(wǎng)絡狀態(tài)下有緩存上溢的風險，最后的抑制和激勵部分則需要在接收端可控的情況下實現(xiàn)。以后將在更多的嵌入式平臺以及復雜網(wǎng)絡上進行實驗，驗證算法的適應性，改進以提高緩存的穩(wěn)定性和算法的性能。