多路視頻硬件壓縮與傳輸系統設計與實現

胡 斌，劉 臺，高 超，王進舉，龔 鵬

（武漢中原電子集團有限公司，湖北 武漢 430205）

0 引言

隨著通信技術和多媒體技術的快速發展，視頻監控系統在國內外不同行業都有著廣泛的應用，例如商場、居民區等場景中均部署有視頻監控設備，視頻監控技術具有較好的發展和應用前景[1-2]。目前，常見的視頻監控系統主要分為模擬視頻監控系統和數字視頻監控系統。模擬視頻監控系統易受外部干擾，一旦傳輸距離較遠，便會嚴重影響視頻質量。而數字視頻監控系統開發廠商較多，未做到標準統一化，更換維修不方便[3-5]。隨著網絡監控的引入、網絡協議與網絡設備的逐漸完善以及嵌入式設備的快速發展，出現了專門針對視頻進行采集編碼的高集成度芯片。

基于全志T7 的四路視頻硬件壓縮與傳輸系統采用模擬高清（AnalogHighDefinition，AHD）攝像頭進行視頻數據采集，利用同軸線纜可實現遠達500 m 的高清無損視頻傳輸，解決了傳統模擬視頻監控系統遠距離傳輸導致視頻質量較差的問題，并減少了接口引線工程。視頻處理采用嵌入式全志T7 平臺，利用該平臺對視頻進行H.264 硬件壓縮，解決嵌入式CPU 性能低的問題。此外，在T7 平臺上部署視頻服務器，基于實時流傳輸協議（Real Time Streaming Protocol，RTSP）實現低時延網絡推流傳輸。

1 系統硬件平臺

該系統由4 個AHD 攝像頭、全志T7 芯片、NVP6324 芯片以及控制終端組成，如圖1 所示。

圖1 系統硬件平臺

利用AHD 攝像頭采集視頻信號并傳輸至NVP6324 芯片，NVP6324 芯片將視頻模擬信號轉換為移動行業處理器接口（Mobile Industry Processor Interface，MIPI）信號并傳輸到全志T7 處理器，全志T7 處理器獲取到視頻數據后對其進行編碼和網絡流傳輸。其中視頻采集基于Linux 的V4L2 軟件框架，編碼方式采用H.264 硬件編碼。H.264 的壓縮算法強于傳統的M-JPEG，壓縮率一般能達到1 ∶70～1 ∶150，對網絡實時傳輸要求更低[6]。H.264 壓縮有兩種方式，即軟件壓縮和硬件壓縮。由于軟件壓縮的CPU 占用較高且處理速度慢，因此該系統采用硬件壓縮。此外，視頻推流傳輸采用RTSP 協議。RTSP 協議是一個用于流媒體傳輸控制的協議，以C/S（客戶端/服務器）方式工作，具有網絡傳輸時延低的特點[7]。

整個系統的工作流程為：首先全志T7 基于V4L2 采集壓縮前的攝像頭YUV 視頻格式數據；其次對YUV 數據進行H.264 硬件壓縮；再次利用FFmpeg 對壓縮后的H.264 數據進行RTSP 網絡推流；最后將RTSP 視頻流數據經全志T7 搭建的Easydarwin流媒體服務器通過局域網發送至客戶端。

2 系統軟件設計

軟件設計包括視頻采集、視頻編碼以及視頻推流設計，部署在全志T7 平臺上，操作系統采用Linux 3.1.0。

2.1 視頻采集

視頻采集單元基于Linux 下的V4L2 規范，當文件映射到操作系統的進程地址空間后，相關模塊可以對文件進行訪問，減少了數據拷貝操作，可以極大地提高效率[8]。視頻采集流程如圖2 所示。

圖2 視頻采集流程

2.2 視頻編碼

2.2.1 H.264 硬件編碼

視頻編碼采用H.264 編碼方式，包含數據探測、數據轉換、數據量化等[9]。H.264 編碼有兩種方式，即軟件編碼和硬件編碼。其中，硬件編碼效率高，并且不占用額外的CPU 資源。全志T7 具有AW Video Encoder 硬件編碼庫，只需指定常用的輸入輸出數據格式，其余參數會默認設置為常用最優值。上層通過簡單調用實現編碼，無需關心內存、硬件、平臺、SDK 版本等差異。H.264 硬件編碼流程如圖3 所示。

圖3 視頻硬件H.264 編碼流程

2.2.2 H.264 硬件編碼優化

針對網絡丟包現象，H.264 編碼利用解碼重同步技術提高了系統的魯棒性。當出現序列集中數據丟包或數據錯位時，可以及時恢復。H.264 解碼重同步如圖4 所示。

圖4 H.264 解碼重同步

當視頻中運動物體較多時，采用分塊運動補償技術，將每幀分為若干像素塊，從參考幀某位置等大小的塊對當前塊進行預測。預測過程即為像素塊的平移運動，平移大小利用插值方法確定。此外，采用Lagrangian 算法進行H.264 編碼控制。編碼模式為：

式中：I為編碼模式，λ為Lagrangian 參數，S為樣本，J(S,I/λ)為Lagrangian 代價函數，D(S,I)和R(S,I)為輸出比特流的失真度和碼率。當J(S,I/λ)最小時，編碼模式最優。

對于某一樣本Sk，編碼后的比特率和失真度僅與編碼模式Ik有關：

分別對每一個樣本Sk∈S選擇最優的編碼模式，即可得到J(S,I/λ)的最優值，實現相應的編碼控制。

2.3 視頻推流

2.3.1 推流服務器

搭建流媒體服務器進行視頻流請求的監測，并通過以太網實時推送視頻流。推流服務器采用開源項目EasyDarwin，支持RTSP 等流媒體相關協議[10]。推流服務器的整體架構如圖5 所示。

圖5 視頻推流整體架構

利用EasyCMS 和EasyDarwin 組合的服務器進行RTSP 視頻流監測，實現網絡轉發推送。客戶端停止播放時，推流停止，不占用帶寬。

2.3.2 RTSP 推流

RTSP 是用來控制聲音或影像的多媒體串流協議，對流媒體提供了暫停、快進等控制。其本身不傳輸數據，只提供流媒體服務器的遠程控制，服務器端可以自行選擇使用傳輸控制協議（Transmission Control Protocol，TCP）還是用戶數據報協議（UserDatagramProtocol，UDP）進行數據傳輸。

客戶端與流服務器端建立連接后，服務器向客戶端反饋流數、媒體類型等相關信息，而客戶端與服務器端協商端口信息，通過播放、快進、暫停、快退等命令與服務器端進行通信并實現控制，同時通過命令結束與服務器端的連接。RTSP 推流的實現采用FFmpeg，其是專門用于處理音視頻的開源、免費庫[11-12]。

3 系統測試

3.1 全鏈路時延測試

視頻傳輸的全鏈路時延主要由視頻采集、編碼、推流、網絡傳輸、拉流、解碼以及渲染顯示等過程導致。借助毫秒級精度秒表測試系統中的視頻時延，將4 路AHD 攝像頭同時對準秒表并開啟秒表計時，通過EasyPlayer RTSP 播放器進行視頻解碼顯示。假設時延為ΔT，實際秒表時間為T1，經過解碼顯示后的秒表時間為T2，則：

進行10 次時延測試，測試結果如表1 所示。

表1 時延測試數據

由表1 可知，10 次時延平均值為140 ms，滿足系統低時延要求。

3.2 前端采集編碼推流時延測試

借助程序計數器進行采集、編碼以及推流時延的測試，結果如表2 所示。

表2 采集編碼推流時延測試數據

由表2 可知，視頻采集+編碼+推流的平均時延為38.469 8 ms。其中，視頻推流時延最小。

4 結語

本文設計實現了基于全志T7 的四路視頻硬件壓縮與傳輸系統，可同時滿足4路AHD攝像頭輸入，能夠同時對4 路視頻進行硬件壓縮與低時延網絡傳輸。該嵌入式視頻監控系統具備視頻時延低、可靠性高、可靈活部署等特點，在視頻實時性要求較高的視頻監控領域具有較好的應用前景和研究價值。