基于RTSP的嵌入式視頻監控系統設計※

劉志軍，王建

（華南農業大學工程學院，廣州510642）

引 言

基于以太網的嵌入式視頻監控得到越來越廣泛的應用，如通過3G網絡傳給服務器，將移動機器人所采集到的視頻數據通過3G網絡傳給服務器［1]。流媒體技術也在不斷地普及，將目前流行的流媒體傳輸技術應用到視頻監控系統中是比較好的選擇，既不會占用太多的網絡帶寬，又可以實現較為流暢的視頻監控。本文基于H264編碼技術和對Live555二次開發，設計了一種可對柑橘生長進行視頻實時采集、編碼、傳輸的嵌入式流媒體視頻監控系統。

1 網絡監控視頻技術簡介

1.1 RTSP技術

RTSP［2]（Real Time Streaming Protocol，實時流傳輸協議），屬于TCP／IP協議體系。顧名思義，它是一個用于流媒體傳輸控制的協議，能夠控制流媒體在傳輸過程中的暫停與繼續，從而方便用戶實現播放器的一些基本播放功能。它以C／S方式（客戶端／服務器）工作，由于結合了很多技術上的優點，目前在因特網視頻應用中廣泛流行。

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

圖1 RTSP與RTP、RTCP關系

1.2 H.264技術

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

1.3 Live555開源工程

Live555［4]是一個開源項目，使用C＋＋語言編譯，為RTSP、RTP／RTCP、SIP等標準流媒體傳輸協議提供解決方案，支持目前主流的ts、MPEG、mkv、H264格式的視頻，被大多數流媒體服務器應用選為開發平臺，VLC、ffplay等多款播放器能夠點播使用Live555作為流媒體服務器的視頻數據。Live555有4個基本的庫，即BasicUsageEnvironment、UsageEnvironment、GroupSock和Live－Media。前面三個庫在本設計中均不需要改動，需要改動的是LiveMedia模塊，它是Live555最重要的模塊。這個模塊的主要作用是聲明一個Medium類，在Live555工程中，很多其他類都是它的派生類。

1.4 YUV圖像數據分析

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

圖2 YUV排列格式示意圖

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

2 流媒體服務器的實現

2.1 系統整體結構

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

圖3 系統架構圖

在本設計中，系統平臺為Linux，USB攝像頭的型號為環宇飛揚v8，只支持輸出YUYV排列的YUV422格式的圖像數據，x264目前只支持YUV420P的圖像數據輸入。為了保證穩定可靠，采用FFmpeg工程中的libswscale對其進行數據格式轉換，并利用構建好的RTSP服務器對編碼的數據進行實時發送傳輸。

2.2 構建流媒體服務器

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

2.2.1 SDP獲取代碼二次開發

當RTSPServer收到對某個媒體的DESCRIBE請求時，它會找到對應的ServerMediaSession，調用ServerMediaSession：：generateSDPDescription（）。generateSDPDescription（）中會遍歷調用ServerMediaSession中所有的調用ServerMediaSubsession，通過subsession－＞sdpLines（）取得每個Subsession的sdp，合并成一個完整的SDP并返回。對于不同流媒體格式獲取SDP信息的方式不同，因此，本設計基于OnDemandServerMediaSubsession類構建新的會話類WebcamOndemandMediaSubsession。

獲取SDP信息的函數調用關系如圖4所示。

圖4 獲取SDP函數調用關系圖

sdpLines（）函數在OnDemandServerMediaSubsession類中已經實現，為了順利地獲取SDP信息，需要對sdp－Lines（）運行時調用的幾個函數作一定的修改。因此，需要對OnDemandServerMediaSubsession類中的幾個虛函數進行重載，具體做法如下：

①對于createNewStreamSource函數，因為本設計處理的是H264格式的源，函數中應當加入H264VideoStreamFramer：：createNew（）語句。

②對于createNewRTPSink函數，同理，函數中應當加入H264VideoRTPSink：：createNew（）語句。

③setSDPLinesFromRTPSink取得Subsession的sdp并保存到fSDPLines，這個函數重點是調用getAuxSDPLine，因此需要重構getAuxSDPLine函數。getAuxSDPLine函數所調用的chkForAuxSDPLine也需要重載。對于H.264文件，是不能從rtpSink中取得PPS／SPS的，所以必須調用startPlaying函數對視頻流播放一下才行，播放之后又會關閉，這點在建立連接的時候可以用打印函數調用流程以便了解得更加清楚。在下面的偽代碼中，可以看到之后又調用了chkForAuxSDPLine這個函數，這是為了保證在函數退出前能正確取得AuxSDP，所以在chk－ForAuxSDPLine函數中需要循環檢查是否取得AuxSDP。偽代碼略——編者注。

2.2.2 構建WebcamFrameSource類

WebcamFrameSource屬于一個source類，也就是一個能夠提供視頻源的類。流媒體開發大都具有相似的特征，Live555中也繼承了source和sink的精神，簡而言之，source就是產生數據的對象，而sink節點是數據最終流向的對象，sink的數據必須通過source讀取。Live555工程中雖然已經實現眾多的source，但是并沒有能夠實現直播來自攝像頭過來的數據的功能，因此，二次開發的主要任務之一便是構建新的source，該source應該具有將H264的打包數據存放在內存中，并且能夠傳送給H264VideoRTPSink。本設計中，基于FramedSource構建WebcamFrameSource類。

對于WebcamFrameSource類，主要開發工作是在其構造函數中配置好V4L2采集攝像頭數據，x264編碼優化設置，作為一個source類，每次從該source中取數據時，都會調用doGetNextFrame函數，該函數作為Framed－Source類中的一個虛函數，可以在新構造的Webcam－FrameSource類中進行重載。對V4L2設備的初始化［5]流程如圖5所示。

圖5 V4L2初始化設置

X264視頻編碼初始配置［7]偽代碼略——編者注。

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

在從WebcamFrameSource這個流媒體源中取數據時，都會調用doGetNextFrame這個函數，此函數是FramedSource類中定義的虛函數，因此需要在構建WebcamFrameSource類時進行重載。從流媒體服務器發出一幀數據的流程如圖6所示。

圖6 數據傳輸流程圖

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

3 系統實現

3.1 軟硬件環境

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

3.2 移植要點

本設計中需要編譯的庫文件為x264，以及libswscale，V4L2已經包含在Linux內核驅動中，x264可以下載到單獨的工程，而libswscale包含在FFmpeg工程中［8]。

對于x264工程的編譯，本設計直接從x264官網下載版本號為20140104－2245的源碼，使用如下命令配置：.／configure－－prefix＝／home／x264－－enable－shared－－enable－static－－enable－debug－－cross－prefix＝arm－none－linux－gnueabi－－host＝armlinux

命令的含義大致為安裝目錄為／home／x264，同時編譯靜態和動態庫文件，使能調試，并設置好交叉編譯工具鏈。配置好后使用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－nonelinux－gnueabi－－－arch＝arm

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

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

3.3 系統測試運行

當服務器開啟之后，客戶端PC通過以太網與目標板連接，設置客戶端PC網卡地址，確保在同一IP網段上面，在客戶端給ffplay傳入RTSP：／／192.168.71.128：9554／webcam參數，ffplay的播放效果如圖7所示。畫面基本較為清晰，且實時性較好。

結 語

圖7 運行效果圖

本文構建了一個結合實時視頻采集、編碼和嵌入式技術的RTSP流媒體服務器，并采用目前常用的支持RTSP技術的FFplayer作為客戶端播放器，實現了嵌入式視頻監控系統的設計，整個系統成本低廉，穩定可靠，并且負荷方面基本能滿足中小型應用的要求，具備一定的參考價值。

編者注：本文為期刊縮略版，全文見本刊網站www.mesnet.com.cn。

［1] 劉丙洋，郭文成.3G網絡的移動機器人遠程監控系統［J] .單片機與嵌入式系統應用，2013（2）：59－61.

［2] RFC 2326—1998Realtimestreamingprotocol（RTSP）［S] .

［3] 畢厚杰.新一代視頻壓縮標準H.264／AVC［M] .北京：人民郵電出版社，2005.

［4] LIVE555Streaming Media［EB／OL] .［2014－04] .http：／／www.Live555.com／LiveMedia／.

［5] Bill Dirks，Michael H Schimek，Hans Verkuil.Video for Linux Two API Specification［EB／OL] .［2014－04] .http：／／wenku.baidu.com.

［6] Wikipedia.Session Description Protocol.［EB／OL] .［2014－04] .http：／／en.wikipedia.org／wiki／Session＿Description＿Protocol.

［7] 何勛.基于S3C2440的H.264應用、軟編解碼及優化［D] .成都：電子科技大學，2010.

［8] 王立青，李瑞祥，王延政.基于X264和流媒體的嵌入式視頻監控系統［J] .計算機安全，2011（4）.

［9] 李爭明，張佐，葉德見.一種新的直播服務器實現框架式［J] .計算機應用，2004（11）：41－43.