基于Linux的視頻圖像處理及其網絡傳輸監控系統

李博文， 陳元枝， 姜文英

(桂林電子科技大學 電子工程與自動化學院，廣西 桂林 541004)

目前，視頻網絡監控在國內外都有著廣泛的應用和較大的市場，比如安防系統，在一些商場、居民區、街道、金融機構隨處可見。在諸多應用場合使用的視頻監控系統主要分為2大類：

1)模擬視頻監控系統[1]。該類系統采用模擬信號線傳輸數據，信號易受外部干擾，一旦傳輸距離較遠，視頻質量將會受影響，出現卡頓、馬賽克等現象，主要應用于監控范圍較小的場合，且系統的可擴展能力較弱，存儲信息量非常有限，施工復雜[2]。

2)數字視頻監控系統。由于該類系統的開發廠商較多，并未做到標準統一化，致使視頻設備不具有互換性，視頻平臺建成并交付后，平臺和設備的損壞、更新、維修、維護只能由視頻建設單位提供支持和服務[3-5]。

數字時代的計算機處理器與監控系統大多為傳統的串口總線連接[6]，所以呈現出了一定的弊端，盡管系統圖像處理功能與sensor本身采集功能已較為成熟，但監控端與PC端控制信號傳輸有限，易受到干擾，相對來說不夠完善。如今，網絡監控的引入，各種網絡協議與網絡設備逐漸完善，使得視頻網絡傳輸的帶寬更足，傳輸的數據完整性更有保障。最近幾年，隨著嵌入式技術的快速更新，控制器各個功能日益完善，芯片集成度增高，使得微控制器本身的穩定性、擴展性、運算速度、內存管理系統等性能更加優秀[7-8]。

鑒于此，設計了一種基于嵌入式Linux的視頻圖像處理及網絡傳輸監控系統。該系統相比數字監控方式，不僅減少了接口引線工程，而且在數據傳輸速度、系統性能等各個方面更加完備。在編碼方面，因H.264在壓縮算法方面強于M-JPEG[9]，H.264的壓縮比一般能達到1∶70甚至1∶150以上，而M-JPEG壓縮比一般小于1∶20，且由于高壓縮率，經H.264方式壓縮的圖像數據量遠小于M-JPEG，更利于實時傳輸。

1 系統硬件平臺

硬件平臺框架如圖1所示。該硬件平臺由視頻采樣端攝像頭、HI3518E芯片[10]、串口調試器、有線網卡RTL8201F、USB接口等構成。為了實現視頻采集、處理、網絡傳輸的低成本，低功耗，并能在客戶端實時監控，系統采用一款性價比較高，成本較低的ARM9架構芯片HI3518E。該芯片集成了ARM9內核CPU與DSP的雙核處理器，搭載了AR0130攝像頭、有線網卡RTL8201F等外設。

圖1 硬件平臺框架

該系統處理器內核為ARM926，540 MHz主頻，32 KiB I-Cache，32 KiB D-Cache，集成視頻分析加速引擎。DSP具有支持3D去噪、圖像增強等視頻與圖形處理功能，支持視頻縮放及8個區域的編碼前處理OSD疊加；具有H.264&JPEG多碼流實時編碼能力，支持CBR/VBR/FIXQP三種碼率控制方式，輸出碼率可控范圍為0.002 ～100 Mibit/s。

視頻采集前端的任務主要是利用AR0130攝像頭獲取視頻流，采用H.264編碼技術對視頻流進行幀壓縮，通過Socket網絡編程技術將壓縮后的數據流經WiFi或有線網卡傳送到客戶端。

2 系統軟件平臺搭建

2.1 移植并燒錄U-boot、Kernel、Rootfs

U-boot、Kernel、Rootfs的源碼獲取一般有2種[6]：1)在官網下載原版，并進行移植修改；2)開發商針對目標板移植的簡化版文件。根據需要配置本系統需要的內核模塊，對內核進行裁剪。

圖2 系統根目錄命令行狀態

系統根目錄命令行狀態如圖2所示。將PC機上Ubuntu Linux中事先移植修改的Uboot、Kernel、Rootfs交叉編譯成鏡像文件，燒錄到目標板中的SPIflash，啟動系統進入根文件系統命令行下，在Ubuntu Linux中搭建TFTP服務器，打開搭建過程中定義的專用傳輸文件目錄tftpboot，將應用程序傳入目標板。

2.2 部署根文件系統

海思平臺視頻編碼算法部分未開源，而是以ko文件、靜態鏈接庫或動態鏈接庫方式提供，需要部署到根文件系統指定的目錄，應用層代碼才能正常運行，否則會提示找不到運行時所需要的文件。系統根目錄下部署ko文件與動態庫如圖3所示。

圖3 系統根目錄下部署ko文件與動態庫

3 視頻監控系統服務端設計

3.1 視頻輸入VI(video input)部分

1)創建視頻緩存池。視頻數據緩沖池如圖4所示。在Linux中，使用、釋放內存都需要申請，同樣地，采樣的視頻數據存放也需要申請內存，海思平臺提供了視頻緩存池機制。結合實際業務需要，創建合適的緩存塊個數，塊的個數不能少于實際項目需要的個數，如原始數據存放在緩沖塊Am中，傳入VI后，視頻處理子系統(video process sub-system，簡稱VPSS)部分對數據進行裁剪、旋轉、縮放等處理，根據后續模塊的需求，對原始數據作不同運算，運算后的數據分別放入各自的緩存塊中。

圖4 視頻數據緩沖池

2)視頻輸入設備工作方式。VI設備通道功能框圖如圖5所示。視頻輸入設備可配置2種工作方式：①工作在離線狀態時，VI對攝像頭傳輸過來的視頻數據選擇性地進行一系列運算，如對原始數據進行裁剪、覆蓋等處理，并輸出多路不同分辨率的數據；②工作在在線狀態時，VI將傳入的原始數據直接在芯片內部寫入VPSS，不經過DDR，數據到達VPSS的過程中省去了對DDR的讀寫，節省了圖像數據傳輸時間。這2種模式的切換在安裝驅動時通過設置參數來進行配置，考慮到實時性要求，為了降低時延，本系統設置工作在在線模式下，VI配置方式為insmod hi35xx_sys.ko vi_vpss_online=1。

圖5 VI設備通道功能框圖

3.2 VPSS

圖6為VPSS上下文結構。VPSS部分針對用戶需求對圖像進行去噪等預處理，再傳入VPSS通道，在通道中進行縮放、翻轉、覆蓋、鏡像等圖像處理，最后將視頻數據本地顯示或者通過視頻編碼(video encorde，簡稱VENC)模塊編碼后發送至終端解碼播放。

圖6 VPSS上下文結構圖

3.3 VENC

1)HI3518E芯片VENC部分是一個支持H.264/JPEG兩種協議的編碼器，主要分為AVC(advanced video coding)和JPGE兩部分，本系統H.264的編碼功能在AVC中實現，JPEG編碼的實現在JPEG部分。視頻碼流在VENC中的處理過程可分為對視頻源數據的接收，對視頻數據進行區域處理，視頻數據編碼，視頻流輸出4個步驟。

2)編碼通道處理模塊如圖7所示。編碼通道用來實現圖像的編碼操作，由碼率控制器和編碼器配合完成視頻圖像編碼。碼率控制器用來調整編碼時的編碼速率，編碼器完成編碼功能。

圖7 編碼通道處理模塊

4 視頻網絡傳輸

4.1 實時流傳輸協議

實時流傳輸協議(real time streaming protocol，簡稱RTSP)[12]適用于CS(client server)架構。目標板作為服務器，PC機為客戶端，目標板與PC機之間可以雙向傳輸控制信號，以此來操作視頻流的傳輸。RTSP工作在應用層，基于TCP協議之上，傳輸過程由RTSP協議主動發起流媒體后，通過RTP網絡協議將視頻流數據傳送出去，而RTP/RTCP協議是基于UDP/TCP協議傳輸數據。視頻數據和RTCP協議通過UDP/TCP協議傳輸數據，RTSP協議的控制流部分通過TCP傳輸。

4.2 實時傳輸協議

RTSP協議主要負責服務器與客戶端之間的控制流信息交互，而真正發送數據依托于實時傳輸協議(real-time transport protocol，簡稱RTP)。RTP主要負責對編碼碼流數據按一定格式進行打包，在視頻監控系統中一般與UDP協作，基于UDP協議來完成數據傳輸，所以傳輸過程只考慮數據的實時性，并不能保證數據的完整性。圖8為RTP/RTCP協議網絡流程圖。

5 系統測試

本系統采用目標板Hi3518Ev200作為Server端，操作系統版本為Linux3.4.35。Client端采用PC機，Windows7 64位操作系統，通過安裝虛擬機運行Ubuntu16.04版本的Linux系統，建立交叉編譯工具鏈后，編譯應用層C語言代碼，生成系統運行時的可執行文件。

5.1 視頻質量測試

1)調節Sensor，驅動黑電平[13]參數。黑電平參數取值范圍為[0，255]，當黑電平標準被調高，圖像將變亮，反之，圖像變暗。圖像亮度對比如圖9所示。

從圖9可看出，黑電平值為0時，圖像明顯偏暗，為255時亮度又太高，過于刺眼，經調節后，設置為200時，圖像亮度適中，較為柔和。圖10為黑電平值為200時的圖像亮度。

2)設置FIXQP模式下I幀、P幀宏塊QP值。QP值越低，其量化步長越小，圖像質量越高，圖像信息越豐富，對于處于運動過程的復雜畫面，QP值較低時，編碼碼率超過系統上限，碼率控制失效，畫面會出現花屏、卡頓等現象,QP取值范圍為[0,51]。不同QP值圖像效果對比如圖11所示。通過多次測試，最后選擇I幀、P幀QP值為[20，24]，此時為本系統測試最佳效果。圖12為QP值為[20，24]時的圖像效果。

5.2 視頻壓縮率測試

選取一組運動畫面的中間幀進行視頻壓縮率測試。圖13為H.264分析器解析圖像幀集合，number為69表示I幀壓縮后的size，number為70～85表示P幀壓縮后的size，number為66、67、68分別表示H.264格式中的SPS、PPS、SEI參數。

壓縮前，一幀RGB圖片占用內存大小為2 764 800 Byte，轉換成YUV420格式后，每個像素占用1.5 Byte，一幀圖像大小為1 382 400 Byte，參考幀I幀壓縮比較低，H.264分析器NAL_Size顯示壓縮后的數據大小，通過對1 s內的30幀壓縮圖片求均值，計算得出每幀圖片大小約為12 920 Byte，對比壓縮前后圖片所占內存大小，通過計算得到壓縮率約為1∶107。

圖9 圖像亮度對比

圖10 黑電平值為200圖像亮度

圖11 不同QP值圖像效果對比

圖12 QP值為[20,24]時圖像效果

5.3 RTSP網絡傳輸速率測試

本測試監控播放一段約10 min的視頻，打開Wireshark[14]軟件工具協議分層統計，如圖14所示，

圖13 H.264分析器解析圖像幀集合

Server發送的數據包包括TCP協議包、RSTP協議包、ICMP協議包、UDP協議包，傳輸過程發送169 035個數據包，占232 017 121 Byte，整體傳輸速率為3.409 Mibit/s，轉換為字節為426.125 KiB/s，其中99.86%的數據包為視頻流數據，即168 798個包通過UDP發送，且數據傳輸比特率為3.408 Mibit/s，即426 KiB/s。RTSP協議包占5個包，共1 335 Byte。圖15 為網絡傳輸速率分布。從圖15可看出，服務器平均每秒發送字節約為426 KiB。

圖14 wireshark 協議分層統計圖

圖15 網絡傳輸速率分布

6 結束語

設計了一種基于Linux的視頻圖像處理與網絡傳輸監控系統。該系統主控芯片為HI3518Ev200，運行的操作系統為Linux3.4.35，在PC機上完成了對應用層代碼的編寫，并用合適交叉編譯工具鏈版本進行源代碼編譯，最終生成可執行程序，在目標板上成功運行。