嵌入式多通道無線視頻傳輸的碼率自適應算法

羅際煒，瞿 濤，鄧徳祥*

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

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

0 引言

視頻和圖像作為人們接收信息的載體，一直是嵌入式系統數據采集、處理和傳輸的基礎對象，所以視頻的壓縮和傳輸技術一直是人們的研究重點。同時隨著物聯網應用的不斷擴展，以無線網絡和視頻壓縮與傳輸技術為核心的嵌入式系統也在不斷增多。但是在無線傳輸時，網絡質量和狀態會發生動態變化，在這時保證視頻壓縮和傳輸的服務質量（Quality of Service，QoS）就成了人們必須要解決的問題。

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

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

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

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

但它們都是根據網絡狀態本身對碼率進行優化，并且大部分都基于PC和大型移動網絡（如手機網絡）平臺，沒有針對嵌入式平臺的特點進行調整，所以在嵌入式環境中的表現不是很優秀。

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

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

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

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

1 無線視頻傳輸系統設計

1.1 硬件環境

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

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

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

圖1 系統硬件框架Fig. 1 System hardware framework

圖2 系統設備組成Fig.2 System equipment composition

1.2 軟件數據流

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

圖3 WiFi相機側數據流圖Fig.3 WiFi camera side data flow diagram

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

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

圖4 控制單元側數據流圖Fig.4 Control unit side data flow diagram

1.3 碼率調整與網絡傳輸

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

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

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

2 碼率自適應算法

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

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

2.1 基于網絡狀態的帶寬估計方法

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

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

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

其中:a是2.3節提到的余量。

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

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

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

2.2 結合緩存狀態的碼率平滑方法

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

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

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

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

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

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

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

2.3 算法流程

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

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

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

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

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

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

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

6）統計當前緩存的用量x，并根據式（4）～（5）計算緩存調整碼率ri′。

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

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

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

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

3 實驗與結果分析

3.1 評價指標

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

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

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

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

其中:T為統計的時間窗口大小。

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

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

2）時延。

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

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

3）丟幀率。

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

其中:T為統計的時間窗口大小。

4）抖動。

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

同時本文還會統計緩存中數據量的標準差di來側面評價抖動指標:

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

3.2 結果分析

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

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

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

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

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

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

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

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

在這幾種情況下分別統計QoS的五個指標。

3.2.1 帶寬估計

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

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

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

圖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 各帶寬估計方法的平滑性統計Tab. 2 Smoothness statistics of each bandwidth estimation method

3.2.2 緩存模塊

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

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

如圖11所示，SFB方法的碼率調整更加平穩。DB因為沒有緩存調整，只能根據估算的帶寬來調整碼率，但由于TCP機制存在著短期和長期的波動，還有估算的不確定性，導致其碼率波動很大。根據表3可知，SFB碼率調整的平滑性在幾種情況下都好于其他方法，同時在吞吐量上也有顯著優勢（見圖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 各緩存模塊方法的吞吐量統計Fig.12 Throughput histogram of each buffer method

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

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

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

表4 緩存抖動統計表 單位：KB Tab. 4 Buffer jitter statistics unit:KB

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

表6 丟幀率統計（平均每分鐘的丟幀數量）Tab.6 Frame loss rate statistics（dropped frames per minute）

3.2.3 控制單元

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

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

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

圖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 帶寬利用率統計 單位：%Tab.7 Bandwidth utilization statistics unit:%

4 結語

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

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