一種RTSP嵌入式視頻監控系統的設計

RTSP：即時(shí)串流協(xié)定(Real Time Streaming Protocol，RTSP)是用來(lái)控制聲音或影像的多媒體串流協(xié)議，并允許同時(shí)多個(gè)串流需求控制，傳輸時(shí)所用的網(wǎng)絡(luò )通訊協(xié)定并不在其定義的范圍內，服務(wù)器端可以自行選擇使用TCP或UDP來(lái)傳送串流內容，它的語(yǔ)法和運作跟HTTP 1.1類(lèi)似，但并不特別強調時(shí)間同步，所以比較能容忍網(wǎng)絡(luò )延遲。而前面提到的允許同時(shí)多個(gè)串流需求控制(Multicast)，除了可以降低服務(wù)器端的網(wǎng)絡(luò )用量，更進(jìn)而支持多方視頻會(huì )議(Video Conference)。

基于以太網(wǎng)的嵌入式視頻監控得到越來(lái)越廣泛的應用，如通過(guò)3G網(wǎng)絡(luò )傳給服務(wù)器，將移動(dòng)機器人所采集到的視頻數據通過(guò)3G網(wǎng)絡(luò )傳給服務(wù)器。流媒體技術(shù)也在不斷的普及，將目前流行的流媒體傳輸技術(shù)應用到視頻監控系統中是比較好的選擇，既不會(huì )占用太多的網(wǎng)絡(luò )帶寬，也可以實(shí)現較為流暢視頻監控。本文基于H264編碼技術(shù)和對Live555二次開(kāi)發(fā)，設計了一種可對柑橘生長(cháng)進(jìn)行視頻實(shí)時(shí)采集，編碼，傳輸的嵌入式流媒體視頻監控系統。

1 網(wǎng)絡(luò )監控視頻技術(shù)簡(jiǎn)介

RTSP(Real Time Streaming Protocol)，即實(shí)時(shí)流傳輸協(xié)議，屬于TCP/IP協(xié)議體系顧名思義，它是一個(gè)用于流媒體傳輸控制的協(xié)議，能夠控制流媒體在傳輸過(guò)程中的暫停與繼續，從而方便用戶(hù)實(shí)現播放器的一些基本播放功能。它也以C/S方式(客戶(hù)端服務(wù)器)工作，由于結合了很多技術(shù)上的優(yōu)點(diǎn)，目前在因特網(wǎng)視頻應用中廣泛流行。

圖1 RTSP與RTP、RTCP關(guān)系

RTSP協(xié)議與RTP(Real Time Protocol)協(xié)議、RTCP(Real Time Control Protocol)的關(guān)系如圖1所示，通常而言，RTSP只用來(lái)傳輸控制信息，這些控制信息使得媒體播放器能控制流媒體的傳輸，而流媒體的傳輸則由RTP負責，所以RTSP協(xié)議必須與RTP/RTCP協(xié)議一起配合使用。

1.2 H.264技術(shù)

H.264技術(shù)是目前在視頻編碼壓縮中采用的最為普遍的一種技術(shù)。由于H.264具有更低的碼率，在同等圖像質(zhì)量的前提下，它可以達到更高的壓縮率，與前代MPEG-2相比，壓縮比通常是它的2倍以上;H.264在算法方面更加復雜，所以它相比上代壓縮技術(shù)也能夠提供高質(zhì)量的圖像。而且它的容錯能力也很強，網(wǎng)絡(luò )適應能力非常好。在本設計中，對于動(dòng)態(tài)變化不是很明顯的視頻，H.264顯示出了非常強大的壓縮能力，使得網(wǎng)絡(luò )帶寬大大減少。本設計只采用了H.264的編碼部分，應用目前最為流行的符合H.264規范的x264工程作為編碼器。

1.3 Live555開(kāi)源工程

Live555是一個(gè)開(kāi)源項目，使用C++語(yǔ)言編譯，為RTSP、RTP/RTCP、SIP等標準流媒體傳輸協(xié)議提供解決方案，支持目前主流的ts、mpg、mkv、h264格式的視頻，被大多數流媒體服務(wù)器應用為開(kāi)發(fā)平臺，VLC、ffplay等多款播放器能夠點(diǎn)播使用Live555作為流媒體服務(wù)器的視頻數據。Live555有四個(gè)基本的庫，即BasicUsageEnvironment、UsageEnvironment、GroupSock和LiveMedia。前面三個(gè)庫在本設計中均不需要改動(dòng)，需要改動(dòng)的是LiveMedia模塊，它是Live555最重要的模塊。這個(gè)模塊的主要作用是聲明一個(gè)Medium類(lèi)，在Live555工程中，很多其他類(lèi)都是它的派生類(lèi)。

1.4 YUV圖像數據分析

常用的YUV元素圖像格式有YUV422格式和YUV420格式。YUV422格式中，按照U、V在時(shí)空上的排列順序不同，可以將他們分為YUYV，YVYU，UYVY，VYUY四種不同的排列方式，目前大部分USB攝像頭輸出的原始圖像都是按照YUYV格式來(lái)排列的;按Y和UV的排列方式不同又可以分為打包格式和平面格式，打包格式通常以英文字母planner表示，而平面格式則會(huì )用interlaced表示，打包格式較為常見(jiàn)，它的Y分量和UV分量在內存中是連續放置的，如圖2右側的示意圖所示，而平面格式Y和UV分量則是分開(kāi)放置的，如圖2左側示意圖所示。

圖2 YUV排列格式示意圖

YUV420在排列上和YUV422規律相同，但是Y:U:V是4:1:1的。一般情況下，利用V4L2采集USB攝像頭的視頻數據是YUYV交錯排列的打包YUV422格式的，但是H264編碼庫要求輸入的視頻格式是YUV420P，也即4:1:1的平面格式，所以要經(jīng)過(guò)轉換。本設計采用成熟的libswscale庫來(lái)轉換原始圖像數據。

2 流媒體服務(wù)器的實(shí)現

2.1 系統整體結構

本設計參考目前流行的視頻監控系統，基于Linux的平臺，利用V4L2(Video for Linux Two)函數接口，采集USB攝像頭傳過(guò)來(lái)的數據，因目前一般的USB攝像頭只支持YUYV排列的YUV422格式的數據采集，因此需要將采集到的數據格式轉換為YUV420P之后，再利用x264對每一幀YUV數據進(jìn)行編碼，最后對Live555開(kāi)源工程進(jìn)行二次開(kāi)發(fā)，構建流媒體服務(wù)器。本設計系統總框圖如圖3所示。

圖3 系統架構圖

在本設計中，系統平臺為L(cháng)inux，USB攝像頭的型號為環(huán)宇飛揚v8，只支持輸出YUYV排列的YUV422格式的圖像數據，x264目前只支持YUV420P的圖像數據輸入，因此為了保證穩定可靠，采用FFmpeg工程中的libswscale對其進(jìn)行數據格式轉換，最后利用構建好的RTSP服務(wù)器對編碼的數據進(jìn)行實(shí)時(shí)發(fā)送傳輸。

2.2 構建流媒體服務(wù)器

對于不同的流媒體源，其數據排列格式不同，因而獲取SDP的方法不同。在構建新的流媒體源的基礎上，需要對SDP獲取部分代碼進(jìn)行二次開(kāi)發(fā)。因此，本設計的工作分為下面兩部分。

2.2.1 SDP獲取代碼二次開(kāi)發(fā)

當RTSPServer收到對某個(gè)媒體的DESCRIBE請求時(shí)，它會(huì )找到對應的ServerMediaSession,調用ServerMediaSession::generateSDPDescription()。generateSDPDescription()中會(huì )遍歷調用ServerMediaSession中所有的調用ServerMediaSubsession，通過(guò)subsession->sdpLines()取得每個(gè)Subsession的sdp，合并成一個(gè)完整的SDP返回之。對于不同流媒體格式獲取SDP信息的方式不同，因此，本設計基于OnDemandServerMediaSubsession類(lèi)構建新的會(huì )話(huà)類(lèi)WebcamOndemandMediaSubsession。

圖4 獲取SDP函數調用關(guān)系圖

獲取SDP信息的函數調用關(guān)系如圖4所示，sdpLines()函數在OnDemandServerMediaSubsession類(lèi)中已經(jīng)實(shí)現，為了順利的獲取SDP信息，我們需要對sdpLines()運行時(shí)調用的幾個(gè)函數作一定的修改，因此，需要對OnDemandServerMediaSubsession類(lèi)中的幾個(gè)虛函數進(jìn)行重載，具體做法如下：

A、對于createNewStreamSource函數，因為本設計處理的是H264格式的源，函數中應當加入H264VideoStreamFramer::createNew()語(yǔ)句。

B、對于createNewRTPSink函數，同理，函數中應當加入H264VideoRTPSink::createNew()語(yǔ)句。

C、setSDPLinesFromRTPSink取得Subsession的sdp并保存到fSDPLines，這個(gè)函數重點(diǎn)是調用getAuxSDPLine，因此需要重構getAuxSDPLine函數。getAuxSDPLine函數所調用的chkForAuxSDPLine也需要重載。對于H.264文件，是不能從rtpSink中取得PPS/SPS的，所以必須調用startPlaying函數對視頻流播放一下才行，播放之后又會(huì )關(guān)閉，這點(diǎn)在建立連接的時(shí)候可以用打印函數調用流程以便了解的更加清楚。在下面的偽代碼中，可以看到之后又調用了chkForAuxSDPLine這個(gè)函數，這是為了保證在函數退出前能正確取得AuxSDP，所以在chkForAuxSDPLine函數中需要循環(huán)檢查是否取得AuxSDP。偽代碼如下所示。

rtpsink = sink;

rtpsink->startPlaying(*source, 0, 0);// 開(kāi)始播放

chkForAuxSDPLine(this); // 循環(huán)檢查

sdp_line = strdup(rtpsink->auxSDPLine());//保存

mp_dummy_rtpsink->stopPlaying(); // 停止播放

return mp_sdp_line; // 返回值

2.2.2 構建WebcamFrameSource類(lèi)

WebcamFrameSource屬于一個(gè)source類(lèi)，也就是一個(gè)能夠提供視頻源的類(lèi)。流媒體開(kāi)發(fā)大都具有相似的特征，Live555中也繼承了source和sink的精神，簡(jiǎn)而言之，Source就是產(chǎn)生數據的對象，而Sink節點(diǎn)是數據最終流向的對象，Sink的數據必須通過(guò)source讀取。Live555工程中雖然已經(jīng)實(shí)現好眾多的source，但是并沒(méi)有能夠實(shí)現直播攝像頭過(guò)來(lái)的數據的功能，因此，二次開(kāi)發(fā)的主要任務(wù)之一便是構建新的source，該source應該具有將H264的打包數據存放在內存中，并且能夠傳送給H264VideoRTPSink。本設計中，基于FramedSource構建WebcamFrameSource類(lèi)。

對于WebcamFrameSource類(lèi)，主要開(kāi)發(fā)工作是在其構造函數中配置好V4L2采集攝像頭數據，x264編碼優(yōu)化設置，作為一個(gè)source類(lèi)，每次從該source中取數據時(shí)，都會(huì )調用doGetNextFrame函數，該函數作為FramedSource類(lèi)中的一個(gè)虛函數，可以在新構造的WebcamFrameSource類(lèi)中進(jìn)行重載。對V4L2設備的初始化流程如圖5所示。

圖5 V4L2初始化設置

X264視頻編碼初始配置偽代碼如下所示。

ctx->force_keyframe = 0; // 不使用強制關(guān)鍵幀

x264_param_default_preset(ctx->param, fast, zerolatency); //預設為零延遲

ctx->param.b_repeat_headers = 1;

ctx->param.b_cabac = 1; //支持cabac

ctx->param.i_threads = 1; //緩沖區數據被取完后任使用不會(huì )出現死鎖

ctx->param.i_fps_num = 30; // 幀率為30

ctx->param.rc.i_bitrate = 150; // 默認碼率

ctx->x264 = x264_encoder_open(ctx->param); // 使用設置好的參數打開(kāi)編碼

x264_picture_init(ctx->picture); // 輸出圖像初始化

另外，也需要對libswscale的使用做一定的初始化，在本設計中，libswscale主要用來(lái)轉換V4L2輸出的yuv422格式數據為YUV420，其中主要是配置圖像高度，寬度，輸入輸出格式，涉及到的函數主要是sws_getContext和avpicture_alloc，在此不再做詳細敘述。

在從WebcamFrameSource這個(gè)流媒體源中取數據時(shí)，都會(huì )調用doGetNextFrame這個(gè)函數，此函數是FramedSource類(lèi)中定義的虛函數，因此需要在構建WebcamFrameSource類(lèi)時(shí)進(jìn)行重載。從流媒體服務(wù)器發(fā)出一幀數據的流程如圖6所示。

圖6 數據傳輸流程圖

按照流程圖構造新的流媒體源，并且根據幀率設置讀取兩幀的間隔延遲時(shí)間，能夠滿(mǎn)足實(shí)時(shí)性要求。

3 系統實(shí)現

3.1 軟硬件環(huán)境

服務(wù)器硬件環(huán)境為T(mén)I的DM3730處理器，256MB運行內存，該處理器基于Cortex-A8架構，主頻為1GHz，并采用比較通用的環(huán)宇飛揚V8的USB攝像頭。軟件方面，基于Linux 2.3.32內核，并裝載Angstrom文件系統。

客戶(hù)端為普通PC，運行Ubuntu 10.04，客戶(hù)端連接程序使用FFmpeg項目中的ffplay，該播放器能夠很好的支持RTSP點(diǎn)播。

3.2 移植要點(diǎn)

本設計中需要編譯的庫文件為x264，以及l(fā)ibswscale，V4L2已經(jīng)包含在Linux內核驅動(dòng)中，x264可以下載到單獨的工程，而libswscale包含在FFmpeg工程中。

對于x264工程的編譯，本設計直接從x264官網(wǎng)下載版本號為20140104-2245的源碼，使用如下命令配置。

./configure --prefix=/home/x264 --enable-shared --enable-static --enable-debug --cross-prefix=arm-none-linux-gnueabi- --host=arm-linux

命令的含義大致為安裝目錄為/home/x264，同時(shí)編譯靜態(tài)和動(dòng)態(tài)庫文件，使能調試，并設置好交差編譯工具鏈。配置好后使用make;make install即可得到編譯好的目標板文件。然后將x264.h和x264_config.h復制到目標板的/usr/include目錄，庫文件復制到/usr/lib目錄。

要獲取libswscale，需要先編譯FFmpeg，本設計采用的FFmpeg版本號為0.8.15，配置FFmpeg的命令如下所示。

./configure --prefix=/home/FFmpeginstall/ --enable-shared --target-os=linux --enable-cross-compile --cross-prefix=arm-none-linux-gnueabi- --arch=arm

配置好之后，使用make;make install命令，將安裝目錄下include中libswscale目錄復制到目標板的/usr/include目錄，lib目錄中的libswscale.a和libswscale.so復制到/usr/lib目錄。

然后再使用交叉編譯工具利用剛才編譯好的這些庫文件，編譯目標板可執行的流媒體服務(wù)器主程序，編譯好之后將可執行程序拷貝到目標板的/opt目錄下。

3.3 優(yōu)化

由于運行環(huán)境為嵌入式系統，資源有限，而且又要保證流播放的實(shí)時(shí)性，因此需要做一些調整。本設計中程序運行負擔主要集中在編碼部分，為了減輕編碼負擔，使用libswscale將分辨率為640x480的視頻流轉換為320x240大小的視頻流。在視頻傳輸過(guò)程中，降低幀率，最終確定為15幀的幀率。為了保證實(shí)時(shí)性，對x264編碼參數預設為快速，零延遲。

3.4 系統測試運行

當服務(wù)器開(kāi)啟之后，客戶(hù)端PC通過(guò)以太網(wǎng)與目標板連接，設置客戶(hù)端PC網(wǎng)卡地址，確保在同一IP網(wǎng)段上面，在客戶(hù)端給ffplay傳入RTSP://192.168.71.128:9554/webcam參數。

結語(yǔ)

在當下RTSP技術(shù)被普遍應用的背景下，本文構建了一個(gè)結合實(shí)時(shí)視頻采集、編碼和嵌入式技術(shù)的RTSP流媒體服務(wù)器，并采用目前常用的支持RTSP技術(shù)的FFplayer作為客戶(hù)端播放器，實(shí)現了嵌入式視頻監控系統的設計，整個(gè)系統成本低廉，穩定可靠，并且負荷方面基本能滿(mǎn)足中小型應用的要求，具備一定的參考價(jià)值。