基于Linux的視頻圖像處理及其網(wǎng)絡傳輸監(jiān)控系統(tǒng)

李博文， 陳元枝， 姜文英

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

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

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

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

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

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

1 系統(tǒng)硬件平臺

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

圖1 硬件平臺框架

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

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

2 系統(tǒng)軟件平臺搭建

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

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

圖2 系統(tǒng)根目錄命令行狀態(tài)

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

2.2 部署根文件系統(tǒng)

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

圖3 系統(tǒng)根目錄下部署ko文件與動態(tài)庫

3 視頻監(jiān)控系統(tǒng)服務端設計

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

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

圖4 視頻數(shù)據(jù)緩沖池

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

圖5 VI設備通道功能框圖

3.2 VPSS

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

圖6 VPSS上下文結構圖

3.3 VENC

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

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

圖7 編碼通道處理模塊

4 視頻網(wǎng)絡傳輸

4.1 實時流傳輸協(xié)議

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

4.2 實時傳輸協(xié)議

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

5 系統(tǒng)測試

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

5.1 視頻質(zhì)量測試

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

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

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

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

圖9 圖像亮度對比

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

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

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

5.3 RTSP網(wǎng)絡傳輸速率測試

本測試監(jiān)控播放一段約10 min的視頻，打開Wireshark[14]軟件工具協(xié)議分層統(tǒng)計，如圖14所示，

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

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

圖14 wireshark 協(xié)議分層統(tǒng)計圖

圖15 網(wǎng)絡傳輸速率分布

6 結束語

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