江俊杰，王志明

（南京理工大學 機械工程學院，江蘇 南京210094）

0 引 言

視頻編解碼技術和電子技術的飛速發(fā)展使視頻技術越來越多的被應用到了計算機和智能手機終端的視頻通信等領域，視頻監(jiān)控技術也伴隨著這個過程逐步發(fā)展，并出現(xiàn)了許多數(shù)字視頻監(jiān)控系統(tǒng)，許多基于ARM、DSP等平臺的視頻監(jiān)控系統(tǒng)陸續(xù)出現(xiàn)了[1]。目前，市場已有的嵌入式視頻采集方案多采用專用的芯片。采用專用處理芯片的系統(tǒng)實時性好，但是可選芯片少且算法不夠靈活。采用基于TI雙核芯片的系統(tǒng)開發(fā)周期端，但成本偏高，適用于高端市場[2]。文獻[2]采用的是ARM和DSP的雙處理器，文獻[3]采用的是雙核DSP處理器，這兩種方式均采用了DSP實現(xiàn)，開發(fā)難度大且成本較高，而采用低端處理器將會使系統(tǒng)性能大大降低，圖像實時性或視頻質(zhì)量達不到要求。

基于以上問題，本文設計了一種基于S3C6410硬件平臺和Linux操作系統(tǒng)的視頻監(jiān)控方案。H.264編碼算法能在相同視頻質(zhì)量的情況下節(jié)約30%的網(wǎng)絡帶寬[4]。本方案通過USB攝像頭進行數(shù)字圖像采集，利用符合H.264標準且性能優(yōu)異的X264進行編碼運算，通過RTP協(xié)議實時發(fā)送，并通過客戶端實時解碼播放接收到的視頻信息，實現(xiàn)了實時監(jiān)控。本文設計的監(jiān)控系統(tǒng)開發(fā)流程短，具有廣泛的應用前景。

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

本系統(tǒng)運行S3C6410硬件平臺上的Linux系統(tǒng)之中，系統(tǒng)主要工作流程如下:USB攝像頭獲取圖像一幀后，該一幀圖像經(jīng)過X264編碼器編碼后，采用RTP協(xié)議通過以太網(wǎng)發(fā)送給客戶端主機上，客戶端主機解碼播放，如此循環(huán)便達到實時監(jiān)控的目的?？紤]到在實際監(jiān)控過程中，需要調(diào)用監(jiān)控錄像，因此該方案會將采集到的數(shù)據(jù)保存到SD卡中，方便隨時調(diào)用。

系統(tǒng)方案如圖1所示。

圖1 系統(tǒng)方案

X264的運算復雜度比較高，因此對硬件平臺有一定的要求，這也是X264盡管性能優(yōu)異，但早期在嵌入式平臺得不到廣泛采用的原因之一。S3C6410是一款高性能32位的RISC微處理器，主頻高達667MHz，它采用64／32位內(nèi)部總線架構，具有視頻處理、二維圖形顯示和縮放等硬件加速器功能[5]。另具有存儲器設備、UART串口，USB及以太網(wǎng)等特性。符合本系統(tǒng)的硬件要求。USB攝像頭采用了環(huán)宇飛揚數(shù)碼科技有限公司的5200A型高清攝像頭，內(nèi)部集成了一款高性能圖像處理芯片ZC301P，可以輸出YUV2等格式的視頻幀數(shù)據(jù)，類似設備在市場上可以廣泛獲得且成本低廉。

2 軟件平臺設計

2.1 操作系統(tǒng)平臺的制作

Linux系統(tǒng)除了具有開源、穩(wěn)定和良好的移植性外，還具有優(yōu)秀的網(wǎng)絡功能。因此系統(tǒng)采用Linux操作系統(tǒng)作為軟件的開發(fā)和調(diào)試平臺。從軟件的角度分析，嵌入式Linux系統(tǒng)通常包括引導加載程序、Linux內(nèi)核、文件系統(tǒng)和用戶應用程序這4個層次[6]。

BootLoader（引導加載程序）是在系統(tǒng)加電后執(zhí)行的第一段代碼[7]。本系統(tǒng)的BootLoader采用的是U－boot，源代碼可以在網(wǎng)絡上下載，但是移植之前需要根據(jù)本系統(tǒng)的硬件平臺進行修改和配置編譯。內(nèi)核移植需要注意的地方是在配置內(nèi)核選項時，要根據(jù)所需的硬件資源添加所需驅動程序，主要包括網(wǎng)卡、USB、大容量存儲設備等，使最后編譯的內(nèi)核能夠支持S3C6410硬件平臺。在Linux2.6.30以后的版本中，其編譯配置選項中已包括大部分常用硬件的驅動程序，只需在配置時選中，然后編譯即可。Linux是一種類Unix操作系統(tǒng)[1]，幾乎支持所有的Unix類的文件系統(tǒng)，本系統(tǒng)選用的yaffs2文件系統(tǒng)遵守FHS（filesystem hierarchy standard）[8]，掛載時間短，對內(nèi)存的占用小，可讀寫，且嚴格適合嵌入式系統(tǒng)。制作工具選用的是BusyBox。

2.2 基于V4L2的視頻采集程序設計

V4L2是Linux下開發(fā)視頻采集設備驅動程序的一套規(guī)范，為Linux的視頻驅動提供了統(tǒng)一的接口，使應用程序可以使用統(tǒng)一的API函數(shù)進行操作。極大的簡化了視頻系統(tǒng)的的開發(fā)和維護[9]。本文基于V4L2規(guī)范設計的圖像捕捉程序流程圖如圖2所示。

圖2 視頻捕捉程序流程

在圖像捕捉程序中，設計了多線程以提高處理器的效率，其中的mmap線程將捕捉的一幀視頻數(shù)據(jù)通過mmap映射的方式將內(nèi)存映射到X264編碼緩存中，避免在用戶空間和內(nèi)核空間之間不斷拷貝數(shù)據(jù)而大量占用用戶內(nèi)存空間，浪費寶貴的內(nèi)存資源。

2.3 X264編碼器移植

X264編碼器是針對X86平臺的，移植到嵌入式平臺程需要對源代碼進行修改，本文選取幾處加以說明:

從網(wǎng)絡上下載解壓源代碼后，進入X264目錄進行配置。參考配置命令:

[root＠localhost x264＿arm]＃.／configure－－h(huán)ost＝arm－linux －－prefix＝／x264 －－extra－cflags＝－mtune＝arm1176jzf－s－－enable－shared－－disable－arm

在配置選項中注明了cpu內(nèi)核類型，否則即使編譯成功，arm平臺上的X264編碼器仍將無法正常運行。配置完成后，會在當前目錄生成一個config.mak文件，還需要對該文件中的幾個選項進行修改。找到其中的ARCH、CC、LD、AR、RANLIB以及STRIP項，將它們分別改為:ARCH＝ARM、CC＝arm－linux－gcc、LD＝arm－linux－gcc－o、AR＝arm－linux－ar rc、RANLIB＝arm－linux－ranlib 、STRIP＝arm－linux－strip。代碼修改完成之后，執(zhí)行 make命令，至此，X264移植完成。

2.4 X264編碼程序設計

本文選用的H.264編碼器選用了X264，相比其他編碼器，X264更注重實用，去除了一些對編碼性能影響很低但計算復雜度很高的新算法，降低運算復雜度[10]。X264編碼器的編碼流程如下:

（1）設置默認參數(shù):

x264＿param ＿default＿preset（x264＿param ＿t＊，const char＊preset，const char＊tune）；

（2）設置其他編碼參數(shù)，根據(jù)實際情況進行設置，需要注意的參數(shù)有:

（3）參數(shù)修正并初始化:

x264＿encoder＿open（x264＿param＿t＊）；

（4）編碼一幀參數(shù):

x264＿encoder＿encode（x264＿t＊，x264＿nal＿t＊＊pp＿nal，int＊pi＿nal，x264＿picture＿t＊pic＿in，x264＿picture＿t＊pic＿out）；

（5）關閉編碼器:

x264＿encoder＿close（x264＿t＊）；

目前的X264編碼器輸入圖像格式只支持YUV2格式，而本文所選用的USB攝像頭輸出格式為YUV422格式，因此需要進行格式轉換之后才可以被編碼器正常編碼。編碼完一幀后的數(shù)據(jù)儲存在pp＿nal.p＿payload中，需要在下一次調(diào)用x264＿encoder＿encode編碼函數(shù)前將數(shù)據(jù)取出。在最新版的X264編碼器中，上述編碼函數(shù)已經(jīng)調(diào)用NALU打包，編碼后的數(shù)據(jù)在經(jīng)過簡單的處理后就可以進行RTP打包。

2.5 基于RTP協(xié)議的發(fā)送程序設計

對于H.264視頻的實時傳輸應用來說，TCP的重傳機制引入的時延和抖動是無法容忍的?；赨DP只上的高層協(xié)議 實 時 傳 輸 協(xié) 議 （real－time transport protocol）RTP／RTCP是目前解決流媒體實時傳輸問題的最理想方法[1]。RTP能夠提供端到端傳輸服務，位于TCP和UDP協(xié)議只上，適合通過組播和點播傳送實時數(shù)據(jù)[11]。該協(xié)議還提供了流量控制和擁塞控制服務。典型的基于RTP／UDP／IP的H.264視頻傳輸框圖如圖3所示。

圖3 H.264視頻傳輸框架

對于H.264的數(shù)據(jù)流打包協(xié)議，最新的RFC3984標準中提供了針對H.264媒體流的RTP打包方法。X264編碼器編碼出的一幀數(shù)據(jù)并不能直接打包發(fā)送，在編碼函數(shù)中，除了寫入NALU頭，也加入了前綴用來區(qū)分各個NALU，在打包發(fā)送前，需要將前綴去除。最后根據(jù)RFC3984標準，本文基于RTP協(xié)議的發(fā)送程序中的數(shù)據(jù)打包算法流程如圖4所示 （圖中MTU即最大傳輸單元）。

圖4 數(shù)據(jù)打包算法流程

RTP協(xié)議基于UDP之上，因此在實現(xiàn)RTP打包發(fā)送前，需要創(chuàng)建一個Socket，并且需要指定接收端的IP地址及接收端端口號，完成UDP初始化之后，RTP發(fā)送的數(shù)據(jù)才會被客戶端接收到。在設定RTP的參數(shù)中，需要設定RTP負載類型以及時戳，根據(jù)RFC3984，對于H.264視頻格式，并沒有規(guī)定一個默認的值，選用一個大于95的值即可，但與時戳相應的時鐘頻率必須為90000Hz。

2.6 X264編碼器優(yōu)化思路

針對x264編碼器運算復雜的特點，本文主要從以下3種思路優(yōu)化編碼器源代碼以減小編碼耗時，提高編碼的實時性:

（1）源代碼精簡。

X264源代碼中，有許多變量及函數(shù)語句與編碼并無直接關系，這些被定義的變量和結構體會占用一部分內(nèi)存空間。此外大部分的調(diào)試信息輸出語句都可以被刪除。

（2）設定合適的X264編碼參數(shù)。

X264支持多種類型的編碼框架，即Baseline，Main和多種更高等級。其中，Baseline方式針對交互式應用，復雜度低，低延時，適合實時編碼。參數(shù)設定命令如下:

x264＿param＿apply＿profile（param，x264＿profile＿names[0]）；／／使用baseline

X264有3種碼率控制方式，對于實時編碼傳輸?shù)那闆r，一般采用固定碼率方式。參數(shù)設定命令如下:

param－＞rc.i＿rc＿method＝X264＿RC＿CRF；

（3）算法優(yōu)化

運動估計是H.264標準中最重要且最耗時的一部大約占用這個視頻編碼的60%～80%的時間，也是H.264標準中最重要的環(huán)節(jié)[12]，嚴重影響了X264的實時編碼性。算法優(yōu)化復雜繁瑣，將作為后期主要優(yōu)化方向。

3 系統(tǒng)測試

3.1 系統(tǒng)測試平臺:

系統(tǒng)的嵌入式平臺選用的是飛凌公司的OK6410開發(fā)系統(tǒng)，嵌入式系統(tǒng)采用的Linux內(nèi)核為2.6.36，交叉編譯器版本為arm－linux－gcc 4.3.2，X264編譯器版本為 x264－snapshot－20120315－2245，接收端是PC機 （windows）。

為方便開發(fā)階段的調(diào)試工作，在主機端建立了基于NFS的根文件系統(tǒng)，并將其掛載到嵌入式系統(tǒng)中，NFS根文件系統(tǒng)的主機端是運行于VMware Vorkstation下的Red Hat Enterprise Linux 5系統(tǒng)。ARM板與PC機通過RS232串口傳遞調(diào)試信息，通過網(wǎng)絡接口傳遞視頻數(shù)據(jù)。

3.2 測試結果與分析

將系統(tǒng)的硬件平臺連接之后，為了掛載NFS根文件系統(tǒng)方便調(diào)試，需要將ARM端和PC端的IP置于同一網(wǎng)段中，并使用ping命令檢查，測試結果如下:

[root＠localhost rtp]＃ ping 10.10.40.39

PING 10.10.40.39 （10.10.40.39）56 （84）bytes of data.

64bytes from 10.10.40.39:icmp＿seq＝1ttl＝64time＝4.84ms

64bytes from 10.10.40.39:icmp＿seq＝2ttl＝64time＝0.358ms

……

程序運行前，應當確保系統(tǒng)能加載USB攝像頭驅動，正常情況下，當插入USB攝像頭時，會出現(xiàn)以下調(diào)試信息:

usb 1－1:new full speed USB device using s3c2410－ohci and address 2

usb 1－1:New USB device found，idVendor＝058f，id－Product＝3880

……

uvcvideo:Found UVC 1.00device USB 2.0PC Camera（058f:3880）

input:USB 2.0PC Camera as／class／input／input1

以上檢查工作完成后，表明網(wǎng)絡及硬件可以在嵌入式平臺上正常運行。

啟動監(jiān)控系統(tǒng)，出現(xiàn)以下關于X264的調(diào)試信息:

x264[info]:using cpu capabilities:none！

x264[info]:profile Constrained Baseline，level 3.2

上述表明了設定的X264編碼類型等信息。

接著出現(xiàn)的是發(fā)送的NALU包的信息，如圖5所示。

圖5 調(diào)試信息

從輸出的調(diào)試信息中可以看到，前兩個NALU的類型是7和8，對應著的NALU類型是序列參數(shù)集 （sequence parameter set，SPS）和圖像參數(shù)集 （picture parameter set，PPS），H.264的SPS和PPS串包含了初始化H.264解碼器所需要的信息參數(shù)，包括編碼所用的圖像的高和寬，profile，level等信息。

出現(xiàn)調(diào)試信息后，用VLC播放器打開編寫好的SDP文件，可觀察到實時播放效果如圖6所示。

圖6 實時播放畫面

經(jīng)過多次實驗比對，在QCIF分辨率，X264編碼器未優(yōu)化的前提下，ARM端的最大編碼速度能夠滿足實時播放編碼 （15fps）的要求。在經(jīng)過簡單的編碼器源代碼裁減等優(yōu)化后，最大幀率還能增加，實時性較好，且延時很低。

雖然在實驗過程中的實際幀率能夠達到實時編碼的要求，但是也能看到，即使設定合適的編碼參數(shù)以及精簡部分源代碼，編碼器的效率仍未能得到有效提高，這是因為X264編碼器大部分的時間都在做運動估計相關方面的函數(shù)運算，所以運動估計算法的優(yōu)化將是編碼器優(yōu)化的主要方向。

4 結束語

本系統(tǒng)采用了高性能處理器S3C6410為主控芯片，設計了一種基于X264的嵌入式監(jiān)控系統(tǒng)方案，系統(tǒng)運行于該硬件平臺，通過移植Linux操作系統(tǒng)和X264編碼器，使用RTP協(xié)議，充分發(fā)揮了X264編碼器高壓縮率的特性和RTP協(xié)議良好的實時傳輸品質(zhì)，實現(xiàn)了QCIF分辨率下的實時編碼發(fā)送，并將編碼后的文件保存在SD卡中。實驗過程中發(fā)現(xiàn)，隨著壓縮比的提高，編碼器編碼幀率將會下降，這主要是由于處理器性能的限制和編碼器本身較高的計算復雜度決定的。如何對編碼器進行合理化裁剪和算法優(yōu)化仍將是以后學習中的主要工作。此外，ARM架構處理器發(fā)展迅速，使用性能更好的ARM芯片也是發(fā)揮H.264優(yōu)良的編碼功能，提升系統(tǒng)性能的一個重要方向。

[1]PENG Tiegang，LIU Guofan，CAO Shaokun，et al.Design of embedded video surveillance system based on ARM[J].Computer Engineering ＆ Design，2010，31 （6）:1191－1194 （in Chinese）.[彭鐵鋼，劉國繁，曹少坤，等.基于ARM的嵌入式視頻監(jiān)控系統(tǒng)設計[J].計算機工程與設計，2010，31（6）:1191－1194.]

[2]MA Yongjun，GUO Lei.Design of embedded digital home security video capture system[J].Journal of Tianjing University of Science ＆ Technology，2011，26 （2）:65－69 （in Chinese）.[馬永軍，郭磊.嵌入式數(shù)字家庭安防視頻采集系統(tǒng)設計[J].天津科技大學學報，2011，26 （2）:65－69.]

[3]ZHENG Hui，YANG Fumin，TU Gang.Embedded video supervisory terminal based on dual－cores DSP[J].Computer Engineering ＆ Design，2007，28 （9）:2092－2095（in Chinese）.[鄭輝，陽富民，涂剛.基于雙核DSP的嵌入式視頻監(jiān)控終端[J].計算機工程與設計，2007，28 （9）:2092－2095.]

[4]ZHANG Hongtao，WANG Yang，MAO Hongfei，et al.Design of embedded video surveillance system based on H.264[J].Journal of Hubei University of Technology，2010，25 （5）:11－13（in Chinese）.[張洪濤，王洋，毛洪飛，等.基于H.264的嵌入式視頻監(jiān)控系統(tǒng)的設計[J].湖北工業(yè)大學學報，2010，25 （5）:11－13.]

[5]SAMSUNG Electronics.S3C6410x32－bit RISC microprocessor user's manual（revision1.2）[EB／OL].http:／／www.samsung.com，2011.

[6]GAO Wenhui，SHI Yibing，ZHANG Wei.Implementation of double boot in U－BOOT based on S3C2440[J].Measurement＆Control Technology，2012，31 （2）:87－91 （in Chinese）.[高文輝，師奕兵，張偉.基于S3C2440的U－Boot雙啟動實現(xiàn)[J].測控技術，2012，31 （2）:87－91.]

[7]DU Haixing.Analysis and porting of embedded bootloader based on ARM[J].Mircocomputer Information，2010，26（29）:58－59 （in Chinese）.[杜海星.基于 ARM 的嵌入式Bootloader分析與移植[J].微計算機信息，2010，26 （29）:58－59.]

[8]Rusty Russell，Daniel Quinlan，Christopher Yeoh.Filesystem hierarchy standard[EB／OL].http:／／www.pathname.com／fhs／，2004.

[9]LIU Sheng，ZHAO Jingjing，F(xiàn)AN Xiuli.The embedded video surveillance system based on V4L2[J].Microcomputer Applications，2011，32 （1）:37－42 （in Chinese）.[劉升，趙晶晶，范秀麗.基于V4L2的嵌入式視頻監(jiān)控系統(tǒng)[J].微計算機應用，2011，32 （1）:37－42.]

[10]WU Ping，CHEN Xiuhong，ZHANG Ping.Design of video monitoring system based on embedded X264[J].Video Engineering，2011，35 （7）:108－110 （in Chinese）.[吳平，陳秀宏，張平.基于X264的嵌入式視頻監(jiān)控系統(tǒng)設計[J].電視技術，2011，35 （7）:108－110.]

[11]Connie A，Nasiopoulos T，Leung PVCM，et al.Video paeketization techniques for enhancing H.264video transmission over 3GNetworks[J].Consumer Communications and Networking Conference，2008 （12）:800－804.

[12]HUANG Chunqing，QIU Xiaobin.Optimization on fastmotion estimation algorithm base on X264[J].Control Enginerring of China，2010，17 （6）:821－823 （in Chinese）.[黃春慶，邱曉彬.基于x264的快速運動估計算法優(yōu)化[J].控制工程，2010，17 （6）:821－823.]