??? 摘 要： 一種基于嵌入式Linux和S3C2410平臺設計的遠程視頻自適應傳輸系統" title="傳輸系統">傳輸系統,該系統對視頻的編碼壓縮和傳輸作了改進設計。通過對改進設計的模擬實驗，證明了改進的設計能夠在網絡可用帶寬不穩定的情況下保持視頻接收端緩存數據的持續高占有率，有效地減少了視頻播放的抖動。
??? 關鍵詞： SCTP? 嵌入式Linux? 視頻采集? 自適應? NS2
?
??? 同TCP一樣，流控制傳輸協議SCTP（Stream Control Transmission Protocol）[1]是一種可靠的、提供面向連接的、點到點數據傳輸協議，它繼承了TCP強大的擁塞控制、數據包丟失發現等功能。但是，SCTP具有的一些獨特的性質[2]，如多宿（Multi-homing）、多流（Multi-streaming）、部分有序（Partial Ordering）和塊（chunk）綁定等，因此比TCP更適合在WWW、MPEG4等業務中使用。在一般的視頻采集系統中，由于不能根據傳輸網絡的擁塞狀況實時地調整編碼壓縮參數和發送速率，導致接收端的視頻回放、緩沖數據停滯播放等，給用戶帶來不好的視覺感受。針對這個問題，本嵌入式遠程視頻采集傳輸系統采用SCTP傳輸協議[3]，并且采取一些改進的設計策略，使得該系統可以根據網絡擁塞狀況自適應地實現編碼壓縮和傳輸，減少丟失包，從而達到客戶端視頻播放流暢的滿意效果。
1 硬件平臺和軟件環境
??? 本嵌入式遠程視頻采集傳輸系統硬件平臺選用北京恒豐銳科科技有限公司的HFRK2410開發板。該開發板是基于SAMSUNG S3C2410X高性能ARM處理器的嵌入式開發平臺，穩定工作頻率為202MHz, 帶有64MB SDRAM 64和64 NAND FLASH存儲器，一個USB主機接口，一個USB設備接口，CS8900以太網控制器以及其他設備和模塊。
??? SCTP是Linux 2.6 Kernel中新增加的一個傳輸層協議，因而必須使用2.6以后版本的Linux Kernel，同時在編譯Linux Kernel時，要加入對SCTP模塊的支持。
??? Networking ---> Networking options ---> SCTP Configuration (EXPERIMENTAL) --->
???
??? [*] SCTP：Debug messages
??? [*] SCTP：Debug object counts
??? 該系統采用USB攝像頭獲取實時視頻，所以把USB 模塊和Video4Linux模塊的支持全部加入進來。
????Device Drivers ---> Multimedia devices ---> <*> Video For Linux
??? Video For Linux ---> [*] V4L information in proc filesystem
??? Device Drivers ---> USB support ---> USB support ---> <*> USB OV511 Camera support
??? 有了以上基本設置，就可以在此編譯的內核中進行系統平臺的開發和運行了。
2 系統自適應設計和實現
??? 本系統在運行中需要實時獲知網絡的阻塞情況才能自適應地進行編碼壓縮和傳輸，所以需要在應用程序的視頻發送子模塊獲得關于當前網絡的阻塞情況并把這些信息反饋給視頻編碼" title="視頻編碼">視頻編碼壓縮模塊，讓它們根據當前網絡阻塞信息作相應的調整，從而達到設計本系統的最終目的。因而在應用層獲知當前網絡阻塞情況是本系統設計和實現的主要目標。
??? 傳輸層的SCTP把當前網絡阻塞情況隔離在應用層之下，按照要求修改SCTP協議代碼并重編譯加載是不錯的辦法，但是本系統采取了另一種方法，那就是通過跟蹤應用層視頻發送子模塊時發送數據緩沖的變化情況來探測網絡阻塞狀況。
2.1 自適應視頻發送實現
??? 視頻發送子模塊以一定的速率發送視頻數據" title="視頻數據">視頻數據。當網絡阻塞加重時，發送數據緩沖的待發送視頻數據占的比例會增大；相反，當網絡阻塞減輕時，發送數據緩沖的待發送視頻數據占的比例也會跟著減小。表1給出了緩沖區在tk時刻和tk+1時刻的變化狀況。
???????????????????????? 
??? 緩沖狀況的變化公式如下：
??? 
?
??? 當時刻tk和時刻tk+1間隔足夠小時，式(1)可以寫成：
??? 
??? 變化式(2)：
??? 
??? 
????
?
(其中β為正常參數，且0≤β≤1)
??? 
?
則式(5)可簡化并插入調整幅度參數A（A為正整數）：
??? 
?分析式(7)知，當α為正，即緩沖占用比率增大時，表示由于網絡阻塞加重，則
減小，輸入量將減少；當α為負，即緩沖占用比率減小時，表示由于網絡阻塞減輕，則
增大，輸入量將增大。視頻傳輸初始開始時, 視頻發送子模塊以設定的初始速率
發送視頻數據。其后視頻發送子模塊在固定的時間間隔內根據上面的算法進行網絡負載判斷，并計算相應的發送速率調整系數。當網絡擁塞時，發送速率
減小;當網絡空閑時，發送速率
增加。
2.2 自適應視頻編碼壓縮實現
??? Linux系統中的視頻子系統Video4Linux為視頻應用程序提供了一套統一的API，視頻應用程序通過標準的系統調用即可操縱各種不同的視頻捕獲設備。Video4Linux向虛擬文件系統注冊視頻設備文件,應用程序通過操作視頻設備文件實現對視頻設備的訪問。在視頻采集模塊中獲取圖像數據" title="圖像數據">圖像數據后,將對原始的圖像數據進行壓縮編碼，以方便在網絡中傳輸。XviD是一個開放源碼的MPEG-4多媒體編碼解碼器，它是基于OpenDivX而編寫的。XviD支持多種編碼模式，具有量化(Quantization)方式和范圍控制，運動偵測(Motion Search)和曲線平衡分配(Curve)，動態關鍵幀距(I-frame interval)，心理視覺亮度修正，演職員表選項，外部自定義控制，運動向量加速(Hinted Me)編碼，畫面優化解碼等眾多編碼技術，對用戶來說功能十分強大。在本系統視頻編碼壓縮模塊中，采用XviD編碼解碼器對原始圖像數據進行MPEG-4視頻編碼。
??? 在評價遠程視頻系統時，人的主觀視覺感受往往是最關鍵的。當觀看實時傳輸視頻圖像時，最不可忍受的是視頻停滯緩沖或回放，它會使觀看效果非常糟糕。本系統中采用降低圖像畫面質量的代價來換取圖像的流暢播放的設計。當網絡阻塞嚴重時，如果仍然用保持不變的圖像畫面質量的編碼率對原始圖像數據進行MPEG-4視頻編碼，勢必會導致相同播放時間的圖像數據不能及時正確地傳送到視頻接收子模塊，從而使客戶端播放斷斷續續，給人以極差的主觀感受。本系統的視頻編碼壓縮模塊將根據從視頻發送子模塊傳來的當前網絡的阻塞情況信息，實時調整編碼率。當網絡阻塞減輕時，適當提高編碼率；當網絡阻塞加重時，則適當降低編碼率。
??? 編碼率計算公式如下：
??? 
?
?
其中：γ為正常參數且0≤γ≤1，B為調整幅度參數且為正整數，α由式(6)定義。
??? 在視頻編碼壓縮模塊開始編碼時，以初始編碼率E1進行編碼，在以后的運行過程中，跟隨網絡阻塞狀況進行調整。當網絡擁塞加重時，降低編碼率Ek+1，以便在相同的網絡傳輸數據量包含更多的視頻圖像內容；當網絡轉為空閑時，又將增加編碼率Ek+1，以提高圖像畫面質量。另外考慮到在不同的應用中，對視頻圖像編碼率有各自特別的要求，因而可以設定一個最高編碼率ψ和最低編碼率ω，則Ek+1依次由如下兩式計算后得到：
??? 
2.3 自適應調整算法
??? 根據前述分析，在視頻傳輸初始階段，視頻編碼壓縮模塊以初始編碼率E1進行編碼，視頻發送子模塊以設定的初始速率
發送視頻數據。其后，視頻發送子模塊在固定的時間間隔內（如5s），根據上面的算法進行網絡負載判斷，并計算相應的調整系數α，再根據α情況對視頻發送速率和視頻編碼率作相應調整。具體算法描述如下：
??? (1)傳輸開始時，視頻編碼壓縮模塊以初始編碼率E1進行編碼，視頻發送子模塊以設定的初始速率
發送視頻數據，即E=E1，Sin=
。
??? (2)計算調整系數α：
??? 
?
??? (3)根據調整系數α對視頻發送速率和視頻編碼率作相應調整。為了防止視頻發送速率和視頻編碼率的反復細微變化，只對大于等于一定程度的α做調整計算，否則不更新：
????
?
??? (4)編碼率界限限制計算：
??? 
2.4 自適應算法仿真及結果分析
??? 本系統在實際實施前需要對其中所涉及算法的正確性、參數的有效性進行分析和合理選擇。選用開源免費的網絡模擬仿真軟件NS2[4][5]進行系統仿真分析。需要說明的是，在模擬實驗中，只對算法進行模擬實驗而不是對整個系統進行仿真，因此并沒有真正的采集圖片及編碼，而是采用包頭攜帶不同的信息來表示不同的編碼數據。
???? 網絡拓撲結構如圖1所示，節點0、1、2代表發送端，5、6、7代表接收端，3和4為路由器。3的隊列長度為80，使用FIFO調度和尾部丟棄策略，設置4的隊列長度無限大。節點0、1、2和3以及節點4和5、6、7之間的傳輸速率" title="傳輸速率">傳輸速率都為1.2Mb/s，延遲為100ms；節點3和節點4之間的傳輸速率為2.5Mb/s，延遲為200ms。系統模擬開始時，在0s時由節點0產生發往節點5的1Mb/s的MPEG-SCTP數據[5]，隨后在3s時由節點1和節點2產生發往節點6和節點7的0.8Mb/s的FTP-TCP數據[6]和CBR-UDP數據。而分別在28s、20s和20s時，節點0、1和2停止發送數據，結束模擬。
?????????????????? 
??? 在第一次實驗中，選擇采用恒定傳輸速率
=1.0Mb/s和編碼率E1=420kb/s，每隔0.1s記錄一次節點5的接收數據緩沖占有百分比。圖2為接收節點緩沖數據占有率隨時間變化分布圖。
????????????????????????? 
??? 在第二次實驗中，采用自適應傳輸速率和編碼率，相關初始參數取值如下：
??? 
??? 每隔0.1s就對網絡負載判斷并根據情況進行自適應調整。在實驗中每隔0.1s就記錄一次節點0端編碼率(由于視頻發送速率和編碼率按同一形式公式變化，所以記錄一個就可以了)和節點5的接收數據緩沖占有百分比，如圖3所示。
???????????????????????? 
??? 從圖3中可以看到，在3s之前，由于網絡存在足夠可用帶寬，負載小，編碼率持續增大，直到設定的最高編碼率450kb/s并保持了一段時間。在3s～20s的時間段，由于網絡傳輸延時和另外兩個節點開始發送數據，導致網絡負載加大，MPEG-SCTP數據流與另外兩條數據流進行帶寬爭用，MPEG的編碼率上下波動并且整體趨勢為逐步下降，直到達到設定的最低編碼率350kb/s。在20s后，另外兩條數據流關閉，網絡負載減小，MPEG的編碼率又持續上升，直到450kb/s，并保持。
?? ?另外，對比兩次實驗中的接收節點5的緩沖數據占有率隨時間變化分布圖(圖4)可以看到，恒定傳輸速率和編碼率的實驗中，節點5的緩沖數據占有率變化完全按照MPEG-SCTP數據流與另外兩條數據流進行帶寬爭用的結果變化，這種情況很容易導致視頻播放的不流暢。而在自適應傳輸速率和編碼率的實驗中，接收節點緩沖數據占有率除了與MPEG-SCTP數據流與另外兩條數據流進行帶寬爭用的結果有關，還與節點0的編碼率有關，其結果是雖然網絡負載加大，分給MPEG-SCTP數據流的可用帶寬減少，但是接收節點5的緩沖數據占有率反而有上升的趨勢。這種情況會導致視頻質量下降，但是不會出現播放的緩沖、停滯，相對而言，更能保證實時播放的可視效果。
??????????????????????????????
3 系統實現
??? 把按照本文第1節所述設置編譯的新 Linux 2.6內核燒錄到HFRK2410開發板中，安裝好網眼3000數碼攝像頭，并確定其正常驅動后，就可以開始利用Linux系統中的視頻子系統Video4Linux為視頻程序應用提供一套統一的API，實現視頻采集模塊。獲取圖像數據后，在視頻編碼模塊使用XviD庫對原始圖像數據進行壓縮編碼。另外從 http：//sourceforge.net/上的開源工程中下載SCTP的最新開源代碼KLSCTP，編譯加載模塊后就可以利用其提供的SCTP API接口實現系統的發送視頻模塊和視頻接收模塊。
??? 系統硬件平臺框架圖和模塊劃分見圖5和圖6。
?????????????????????????????? 
??? 基于SCTP的視頻采集傳輸系統的設計及實現，基本利用的是免費和開源的資源，具有穩定可靠、開發容易、修改定制方便、成本低廉等特點，可擴展應用在遠程監控系統、可視電話、工業控制等領域。同時，相對于傳統的類似系統，本系統采用改良了的采集、編碼、傳輸設計策略，能較好地適應帶寬多變的網絡，提高實時視頻的視覺感受質量。但是另一方面，由于其采用的技術都是基于Linux或是開源代碼，因而系統具體實現比較復雜，其中改進的算法也會產生相應的計算開銷。但是隨著Linux技術的普及和計算機運算速度的加快，這個問題將會解決。
參考文獻
[1] STEWART R，XIE Q.RFC 2960：Stream control transmission protocol[S]，2000.
[2] TIMOTHY A，GRIFFIN G，VIEIRA D.A comparison between?two maintenance session protocols.Proceedings of the advanced industrial conference on telecommunications/Service assurance with partial and intermittent resources conference/ELearning on telecommunications workshop，2006.
[3] AHMED ABD EL AL，TAREK SAADAWI，MYUNG LEE.Supporting real-time video in sctp networks.10.1109/MIL-
COM，2006，302104.
[4] The Network Simulator-ns-2[EB/OL].http：//www.isi.edu/nsnam/ns/.
[5] ADAMI D，CALLEGARI C，CECCARELLI D et al.Design，development and validation of an ns2 module for dynamic?lsp rerouting.10.1109/CAMAD，2006.
[6] GOEL A，KRASIC C，LI K et al.Supporting low latency?tcp-based media streams.In Proceedings of International?Workshop on Quality of Service(IWQoS 2002)，Florida，2002，5.