陳宗成，鄧華秋

(華南理工大學理學院物理系，廣東 廣州 510640)

隨著圖像處理技術和網(wǎng)絡技術的不斷發(fā)展，視頻監(jiān)控系統(tǒng)大致經(jīng)歷了三個發(fā)展階段，前兩代分別以黑白電視為代表的模擬監(jiān)控系統(tǒng)和以硬盤錄像機為代表的半數(shù)字化監(jiān)控系統(tǒng)［1］，第三代視頻監(jiān)控系統(tǒng)是指以前端網(wǎng)絡視頻為代表的全數(shù)字視頻監(jiān)控系統(tǒng)，視頻從前端的采集、壓縮、傳輸和瀏覽、存儲全部數(shù)字化。CCD和CMOS攝像頭為數(shù)字視頻采集提供便利。隨著視頻壓縮算法的發(fā)展，高壓縮比、還原能力強的壓縮算法不斷出現(xiàn)，特別是伴隨著流媒體技術產(chǎn)生的H.264視頻壓縮技術，為視頻的實時傳輸和實時瀏覽提供便捷。

伴隨著數(shù)字化視頻監(jiān)控系統(tǒng)的到來，對視頻監(jiān)控系統(tǒng)的要求也不斷提高，要求實時可靠、操作簡單、功能豐富、經(jīng)濟適用等。而嵌入式系統(tǒng)的基本特點恰好滿足了以上要求，嵌入式視頻監(jiān)控系統(tǒng)應運而生。目前嵌入式視頻系統(tǒng)普遍采用BS架構，雖然實現(xiàn)起來簡單方便［2］，卻不利于顯示端功能的升級和改進。本文根據(jù)嵌入式視頻監(jiān)控系統(tǒng)的發(fā)展現(xiàn)狀，在ARM－Linux嵌入式系統(tǒng)上搭建監(jiān)控系統(tǒng)必須的軟件平臺，通過CS架構實現(xiàn)視頻的采集、編碼、發(fā)送和顯示功能。編碼方面采用最新的H.264標準，有效地降低了碼率，和MPEG－2和MPEG－4 ASP等標準相比，在同等圖像質量下，采用H.264技術壓縮后的數(shù)據(jù)量只有MPEG－2的1/8，MPEG－4 的 1/3［3］。在視頻發(fā)送方面，采用協(xié)議 UDP/RTP/RTCP，既滿足視頻服務器所需的組播特性，又能通過RTP/RTCP協(xié)議保證流媒體的實時傳輸［4］。

1 系統(tǒng)結構

本文在ARM－Linux嵌入式平臺實現(xiàn)遠程視頻實時監(jiān)控系統(tǒng)，利用現(xiàn)有的網(wǎng)絡設備，滿足用戶遠程監(jiān)控的目的。需要實現(xiàn)的主要工作包括前端視頻采集、網(wǎng)絡傳輸和終端接收播放，主要功能總結如下:

1)監(jiān)控前端設備通過COMS攝像頭實現(xiàn)視頻的采集;

2)在ARM－Linux平臺對原始視頻數(shù)據(jù)編碼;

3)前端服務器與客戶端通過局域網(wǎng)或者因特網(wǎng)實現(xiàn)視頻數(shù)據(jù)的組播發(fā)送;

4)客戶端接受H.264視頻數(shù)據(jù)，實時解碼播放。

考慮到視頻監(jiān)控系統(tǒng)需要視頻的實時采集、編碼和發(fā)送，因此，需要集成度高、穩(wěn)定、實時性好的SoC系統(tǒng)。在綜合考慮成本的情況下，選擇三星公司S3C6410作為主控芯片。S3C6410是以功能強大的ARM11為核心的SoC芯片，使用廣州友善之臂技術有限公司開發(fā)的mini6410嵌入式平臺。整體硬件平臺如圖1所示。

2 視頻采集、編碼及發(fā)送

2.1 視頻采集

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

利用V4L2接口函數(shù)獲取視頻幀數(shù)據(jù)有3種方式:直接通過read()函數(shù)讀取視頻幀，用戶指針方式，mmap內存映射。本文通過內存映射方式采集，采用這種方法讀取方便，而且省去了大量的內存拷貝，效率較高，具體操作步驟如圖2 所示［5］。

圖2 視頻采集流程

2.2 視頻編碼

本文利用S3C6410提供的MFC硬件編碼器對原始視頻數(shù)據(jù)進行H.264格式編碼，與V4L2視頻采集操作相同，MFC進行編碼時，絕大多數(shù)操作都是通過I/O control接口函數(shù)來完成的，S3C6410已經(jīng)提供了針對H.264視頻編碼的I/O control接口的封裝API函數(shù)。為了減小編程工作量，本文使用這些已經(jīng)比較穩(wěn)定的API函數(shù)進行視頻編碼操作，主要步驟如下:

1)初始化編碼句柄。在進行編碼之前需要初始化一個編碼句柄handles，該變量是一個結構體變量，其中存儲了視頻編碼的控制信息，初始化該結構體的API函數(shù)是:void*SsbSipH.264EncodeInit(unsigned int uiWidth，unsigned int uiHeight，nsigned int uiFramerate，unsigned int uiBitrate_kbps，unsigned int uiGOPNum)。

2)將編碼信息寫入MFC驅動層，初始化MFC硬件。完成這一工作的API函數(shù)是:int SsbSipH.264EncodeExe(void*openHandle)。

3)獲取輸入緩存地址。通過函數(shù)void*SsbSipH.264EncodeGetInBuf(void*openHandle，long size)獲得內核存儲原始數(shù)據(jù)的幀緩存地址。

4)將原始視頻大小存入內核緩沖區(qū)。通過memcpy函數(shù)，將采集到的視頻數(shù)據(jù)發(fā)送該內核驅動空間，用于MFC對視頻進行編碼。

5)對視頻數(shù)據(jù)進行編碼。視頻編碼的API函數(shù)是:int SsbSipH.264EncodeExe(void*openHandle)。在進行編碼時，有些編碼器會在每個關鍵幀前面都添加序列參數(shù)集(Sequence Parameter Set，SPS)和圖像參數(shù)集(Picture Parameter Set，PPS)，造成無用的碼率增加。MFC只對第一幀H.264碼流上添加SPS和PPS。SPS和PPS中含有解碼所必須的參數(shù)，包括幀頻、圖像大小等。

6)獲取編碼后的幀緩存地址和大小。通過API函數(shù)GetOutBuf函數(shù)獲取編碼后視頻數(shù)據(jù)在內核中的緩沖區(qū)地址。返回的編碼數(shù)據(jù)，除了第一幀圖像外，每次緩沖區(qū)內保存的都包含并且只包含一個完整的NAL單元;第一幀圖像編碼完成之后，緩沖區(qū)除了第一個NAL單元之外，還有序列參數(shù)集和圖像參數(shù)集2個NAL單元。

7)將編碼數(shù)據(jù)放入環(huán)形存儲隊列。8)釋放資源，關閉編碼設備。

2.3 視頻發(fā)送

本系統(tǒng)采用流媒體最常用的RTP/RTCP協(xié)議發(fā)送視頻數(shù)據(jù)。編碼后的視頻數(shù)據(jù)按照RTP協(xié)議打包，并利用UDP協(xié)議對局域網(wǎng)組播。RTP協(xié)議的定位是應用層協(xié)議，這樣便于擴展。本文利用RTP的一個C++庫JRTPLIB進行視頻發(fā)送，該庫封裝了網(wǎng)絡協(xié)議的配置，只要調用其中的API函數(shù)就可以輕易配置網(wǎng)絡，不過JRTPLIB本身不是針對某一種實時數(shù)據(jù)的開發(fā)庫，因此，發(fā)送不同的數(shù)據(jù)流需要用戶根據(jù)相應的協(xié)議進行RTP的分包和打包。

1)移植JRTPLIB到ARM平臺

本系統(tǒng)使用的JRTPLIB版本是3.7.1。該C++庫是根據(jù)RTP標準RFC3550寫成的，支持Windows和類Linux操作系統(tǒng)，為用戶提供了RTP頭和網(wǎng)絡配置接口，只要將需要傳輸?shù)臄?shù)據(jù)根據(jù)RTP協(xié)議進行適當修飾就可以輕易使用RTP協(xié)議發(fā)送數(shù)據(jù)。同時，JRTPLIB會自動發(fā)送RTCP控制信息到接收端。

2)初始化RTP會話實例

聲明三個變量:RTPSession rtpsess，RTPSessionParams sessionparams，RTPUDPv4TransmissionParams transparams。

通過實例化類RTPSession建立RTP會話，RTP傳輸?shù)拇蠖鄶?shù)操作都是通過RTPSession對象提供的。同時，用到的2個參數(shù)類是RTPSessionParams和RTPUDPv4 TransmissionParams，分別用來設置RTP協(xié)議的頭信息和傳輸信息。

3)對H.264視頻數(shù)據(jù)進行RTP打包

S3C6410的MFC對視頻進行H.264編碼時，為了存儲到介質上之后解碼器能夠區(qū)分每一個NAL單元，MFC在每一個NAL單元之前添加起始碼0x00000001，這也是H.264標準的建議［6］，但是，實時遠程播放系統(tǒng)，解碼器會根據(jù)RTP時間戳區(qū)分不同的NAL單元，因此在發(fā)送數(shù)據(jù)之前需要去掉該起始碼。為了解碼器獲取序列信息和圖像信息，MFC在第一個NAL單元之前添加序列參數(shù)集和圖像參數(shù)集，這兩個參數(shù)集分別作為獨立的NAL單元與第一個視頻NAL單元形成一個數(shù)據(jù)組。MFC編碼后，輸出緩沖區(qū)內的數(shù)據(jù)結構如圖3所示。

圖3 MFC輸出緩沖區(qū)中數(shù)據(jù)結構

為了將H.264視頻數(shù)據(jù)按照RTP協(xié)議傳輸，并且能夠讓接收端的解碼器能夠識別，需要有統(tǒng)一的標準對H.264數(shù)據(jù)打包和解包。本系統(tǒng)根據(jù)標準 RFC3984［7］對H.264打包。

4)發(fā)送視頻數(shù)據(jù)

JRTPLIB調用RTPSession的成員函數(shù)完成發(fā)送:int SendPacket(const void*data，size_t len，uint8_t pt，bool mark，uint32_t timestampinc)。其中，data是打包完成的視頻數(shù)據(jù)首地址;len是待發(fā)送視頻數(shù)據(jù)長度;pt是發(fā)送的數(shù)據(jù)類型;mark是標示位，本文用來標示一個NAL單元的最后一個分包;timestampinc是時間戳的增量，由于每個NAL單元中的內容都是在同一時刻采集的視頻數(shù)據(jù)，發(fā)送同一個NAL單元分包期間，時間戳不變，該值為0。

3 視頻的接收和播放

本文在PC機上通過會話描述協(xié)議(Session Description Protocol，SDP)［8］文本與發(fā)送端通信，并使用 VLC 播放器解析該協(xié)議文本對視頻流實時播放。

本系統(tǒng)利用BOA網(wǎng)絡服務器將SDP文件發(fā)送到接收端，BOA使用http傳輸協(xié)議。接收端的VLC播放器通過http協(xié)議接收SDP文件，然后對SDP文件解析，通過RTP協(xié)議接收并播放實時視頻數(shù)據(jù)。在PC端，使用VLC播放器通過http協(xié)議打開服務器端的SDP文件實時播放視頻。接收端PC環(huán)境為Intel Core 2 Duo處理器，2.67 GHz，1.75 Gbyte 內存，視頻采集格式為 YUV420，大小480 ×272，幀頻30 f/s(幀/秒)。

圖4a是單個VLC播放器實時播放效果圖，經(jīng)測試，播放延遲在0.5 s以內，考慮到傳輸延時和VLC播放器的緩沖，0.5 s以內的延遲屬于正常。在視頻監(jiān)控期間，丟包率在0.3%以內。圖4b是單個VLC播放器實時播放效果圖。圖4b是4個VLC播放器同時播放效果，表1為同時打開4個VLC播放器測得的數(shù)據(jù)。由于使用組播發(fā)送視頻數(shù)據(jù)，同時打開多個播放器同時進行播放，畫面清晰流暢，沒有明顯抖動，丟包率沒有沒有明顯增加。

圖4 使用VLC播放器實時播放效果

表1 4個VLC播放器信息

4 結論

隨著社會的發(fā)展，視頻監(jiān)控系統(tǒng)成為安防系統(tǒng)中越來越重要的監(jiān)控工具。近些年，網(wǎng)絡技術和視頻處理技術的不斷進步，視頻監(jiān)控不斷向智能化、網(wǎng)絡化和集成化發(fā)展。基于以上背景，本文設計并實現(xiàn)了一款嵌入式實時視頻服務系統(tǒng)。在本文的完成過程中，使用了嵌入式技術、視頻壓縮編碼技術、流媒體實時傳輸技術、SDP會話描述協(xié)議和Web技術，最終實現(xiàn)了基本功能。經(jīng)過測試，視頻播放流暢，支持多用戶同時在線播放，丟包率較低，達到了預期的設計目標。

［1］淺析視頻監(jiān)控系統(tǒng)發(fā)展歷程［EB/OL］.［2012－07－20］.http://wenku.baidu.com/view/4de33302e87101f69e3195a9.html.

［2］楊曉姣，黃云霞.嵌入式視頻監(jiān)控系統(tǒng)視頻服務器的設計與實現(xiàn)［J］.電子設計工程，2011(6):184－186.

［3］胡興軍.視頻編碼標準H.264的技術革新及應用［J］.影像技術，2009(1):24－27.

［4］李長銀.基于UDP組播的分布式仿真系統(tǒng)實現(xiàn)［D］.成都:電子科技大學，2008.

［5］白長青，陳沛.嵌入式終端基于Linux V4L2的圖像采集系統(tǒng)［J］.信息技術，2012(2):22－23.

［6］畢厚杰.新一代視頻壓縮編碼標準——H.264/AVC［M］.北京:人民郵電出版社，2009.

［7］RFC3984，RTP Payload Format for H.264 Video［S］.2005.

［8］王榮生.SDP協(xié)議在視頻點播系統(tǒng)中的應用［J］.計算機應用與軟件，2005(1):74－76.