宮 健,吳 蒙
(南京郵電大學,江蘇 南京 210003)
基于Gstreamer的安全視頻流傳輸系統的實現
宮 健,吳 蒙
(南京郵電大學,江蘇 南京 210003)
文中設計并實現了一種基于PandaBoard ES硬件平臺和Gstreamer開發框架的安全視頻流傳輸系統。在系統中使用了V4L2視頻采集框架、H.264壓縮編碼技術、RTP流媒體傳輸協議實現了端到端的視頻流實時傳輸,并且采用AES加密算法針對實時視頻流進行加密,保證了視頻數據的安全性。文中全面展示了實時視頻系統的搭建過程,并且通過Gstreamer管道測試驗證了該系統方案的可行性。測試結果表明,系統能夠實時、準確、穩定、安全地將現場采集視頻流信息顯示到客戶端,滿足了遠程視頻監控系統的低時延、高安全的需求。
實時視頻傳輸;Gstreamer;H264壓縮編碼;RTP;AES加密
近年來,隨著互聯網的廣泛普及和多媒體技術的飛速發展,人們對基于網絡的實時視頻服務需求不斷增長。典型的網絡實時視頻應用包括交互式視頻服務、視頻電話、遠程教學以及遠程醫療等。而嵌入式媒體平臺由于體積小巧、功耗低、成本低廉的優點,成為了遠程視頻傳輸系統的良好載體[1]。
H.264作為繼MPEG4之后的新一代數字視頻編解碼技術,對實時視頻流傳輸有很好的支持,在能夠還原出高質量圖像的基礎上,不但具備可觀的壓縮比,較低的工作時延,還提供了糾錯檢錯機制[2]。
實時傳輸協議(Real-time Transport Protocol,RTP)是一種網絡傳輸協議,負責對流媒體數據進行封裝,提供了時間信息和同步信息,實現了流媒體數據端對端的實時傳送。但RTP并不保證服務質量,服務質量交由與其配套的實時傳輸控制協議(Real-time Transport Control Protocol,RTCP)來控制[3]。RTP和RTCP均采用UDP協議發送數據包。
AES是美國國家標準技術研究所(NIST)取代DES的新一代加密標準[4],是一種對稱分組密碼體制,使用Rijindael作為核心算法,具有強安全性、高性能、高效率、易用靈活等優點。
文中使用了TI公司的嵌入式平臺PandaBoard ES作為硬件平臺,結合了H.264編碼技術和RTP協議,實現了視頻流端到端的實時傳輸。并以此為基礎,對傳輸的視頻流進行了AES加密,保證了視頻流數據的安全性。
文中所述系統搭建在PandaBoard ES系列開發板上。PandaBoard ES采用OMAP4460[5]作為核心處理器。OMAP4460使用了雙核Cortex-A9對稱架構,其主頻可達1.2 GHz,并且內置了圖形加速器PowerVR SGX540,是一款功能強悍的高性能處理器,可提供對稱多處理(SMP)性能以及豐富的多媒體與3D圖形支持。PandaBoard ES支持包括HDMI v1.3、DVI-D在內的多種媒體接口,搭載了IVA3多媒體加速器,支持全高清、1080p 30 fps多標準高清視頻的錄制與播放[6]。
文中所使用的e-CAM51_44x攝像頭是專為搭載OMAP4系列處理器PandaBoard開發板設計的相機子板。其搭載了具有500萬像素的自動聚焦圖像傳感器OV5640,可以使用V4L2直接驅動,同時PandaBoard提供的100 M以太網口也使得遠端傳輸視頻成為了可能。
2.1 視頻的采集與編碼
(1)V4L2實現視頻采集。
文中系統使用V4L2框架來實現視頻源的采集。V4L2(Video For Linux Two)是Linux系統提供給應用程序訪問音、視頻驅動的統一接口,在嵌入式多媒體終端中有著廣泛的應用[7]。
系統采集的視頻幀格式為YUV,大小為1 080*720,因此在設置視頻采集參數時需指定幀格式為V4L2_PIX_FMT_YUYV,幀高1 080,幀寬720。此外,視頻采集流的幀率V4L2_CAP_TIMEPERFRAME設置成30 fps。
(2)使用H.264進行視頻編碼。
完成視頻采集后,需要將采集的碼流進行壓縮編碼以適應網絡傳輸。文中選用H.264編碼,在獲得較高視頻壓縮比的同時,也能夠保證實時視頻流的傳輸質量。
H.264協議中定義了三種幀:I幀、P幀和B幀[2]。I幀為幀內編碼幀,其編碼不依賴于已經編碼的圖像數據。P幀為前向預測幀,記錄的是該幀與前一個I幀(或P幀)的差別。B幀為雙向預測幀,記錄的是該幀和前后幀的差別。I幀與B幀編碼時都需要根據已編碼的幀(即參考幀)進行運動估計。
在進行H.264壓縮編碼時,存在兩種核心算法:一種是幀內壓縮編碼(也稱為空間壓縮),用于生成I幀。編碼器在實現時會首先選擇相應的幀內預測模式進行幀內預測,隨后對實際值和預測值之間的差值進行變換、量化和熵編碼,同時將編碼后的碼流經過反量化和反變換之后重建預測殘差圖像;然后再與預測值相加以得出重構幀;最后將得出的結果經過去塊濾波器平滑后送入幀緩存。另一種是幀間壓縮編碼,用于生成B幀和P幀。編碼器在實現時,會將輸入的圖像塊首先在參考幀中進行運動估計,以得到運動矢量。運動估計后的殘差圖像經整數變換、量化和熵編碼后與運動矢量一起送入信道傳輸。同時將另一路碼流以相同的方式重建后經去塊濾波再送入幀緩存作為下一幀編碼的參考圖像。當壓縮后的碼流進入解碼器時,解碼器會先判斷。該幀若是幀內編碼所得,則直接進行反量化、反變換加以重建;若是幀間編碼所得,需要根據幀緩存中的參考圖像進行運動補償再疊加補償前的殘缺圖像,從而還原出真實圖像幀。
由于系統的實時性要求很高,文中使用了支持并行處理的X264編碼器對視頻流進行H.264編碼,并且為了使系統獲得更高的性能,訂制了X264編碼框架所使用的參數。將X264的profile參數設定為baseline(基本檔次)以適應視頻實時通信應用。設置比特率參數bitrate為300,設置tune為zerolatency。編碼器會自動工作在低時延狀態,禁用一些會增加時延的功能如sliced-threads(開啟基于分片的線程)、sync-lookahead(啟用線程預測的幀緩存)等。
2.2 實時視頻流網絡傳輸模塊設計
文中系統使用RTP協議來完成端到端的視頻傳輸,并且配合使用RTCP協議來完成網絡流量控制和擁塞控制,保證網絡傳輸的質量[8]。
根據上文所述,當服務器端視頻流完成編碼后,H.264編碼器會將完成的VCL(視頻編碼層)數據封裝到NAL(網絡抽象層)單元中以適應網絡傳輸。RTP協議會對這些NAL單元進行再次打包封裝,寫入時間戳和序列號等信息用以在接收端恢復準確的時間順序。之后放入到RTP發送緩沖區交由UDP處理,封裝成UDP數據包發送至網絡。客戶端接收到數據包時先進行UDP解包,得到RTP數據包,根據RTP包頭的同步信息進行重排序,再對RTP包的負載進行解析。與此同時,使用RTCP協議分析當前網絡狀態。在服務器端,RTCP會周期性的發送SR(發送方報告)包,接收RR(接收方報告包),客戶端則周期性接收SR包,反饋RR包。服務器端根據發送的SR包和接收的RR包分析出丟包率,從而動態調節RTP的發包速率(可以通過調節編碼的速率來實現),以適應當前網絡狀況。整體工作流程如圖1所示。
2.3 基于Gstreamer的視頻傳輸系統實現
文中使用了Gstreamer[9-10]流媒體開發框架設計實現了實時視頻傳輸系統。Gstreamer是一個基于插件和管道結構的媒體開發框架。Gstreamer流媒體框架通過基本元素構件Element相連接組成管道。Element元件根據功能又可以分為Src(數據源)元件、Filter(過濾器)元件、Sink(接收器)元件。而元件內的數據流傳輸又以Pad(襯墊)的形式實現,可分為Src Pad(輸入襯墊)和Sink Pad(輸出襯墊)。

圖1 視頻流網絡傳輸模塊流程圖
當Element元件變得越來越多,數據管道越來越復雜時,Gstreamer允許將一組相互連接的元件組合成一個大的邏輯元件,稱之為Bin(箱柜),從而以對Bin進行操作取代對單個Element元件的操作。
文中系統正是在Gstreamer插件和管道的基礎上,由視頻流管道構成。
(1)服務器端管道。
服務器端的視頻數據流開始于V4L2從攝像頭采集到的視頻數據。使用數據隊列插件queue對采集到的視頻數據流進行緩沖,經緩沖的數據再通過videorate插件調整幀率以得到穩定的、適合播放的視頻輸入源。之后調用X264enc編碼器插件對視頻輸入流進行H264編碼。完成編碼后的碼流開始進入RTP處理流程。首先經過rtph264pay插件進行RTP打包,然后通過rtpbin箱柜。rtpbin箱柜是一個將rtpsession、rtpssrcdemux、rtpjitterbuffer、rtpptdemux組件整合到一個組件的箱柜,用以控制rtp會話,并將數據包以RTP協議封裝(或解封裝),然后交由udpsink插件以UDP包的形式發送至客戶端端口。同時,規定另外兩個端口用于發送和接收RTCP包,rtpbin會根據反饋的RTCP包,進行流量控制和擁塞控制,如圖2所示。

圖2 服務器端管道構成
(2)客戶端管道
客戶端用于監聽數據的端口收到了服務器端的數據流,經由udpsrc插件接收到了UDP數據包,交由rtpbin處理。同時,規定另外兩個端口用于發送和接收RTCP包配合rtpbin進行流量控制和擁塞控制。rtpbin中的rtpjitterbuffer組件能夠緩沖網絡抖動并且將數據包重新排序,將順序正確的RTP包交由rtph264depay插件以將RTP包解包為NAL單元負載流。
使用高性能解碼器ffmpeg對NAL單元負載流進行H.264解碼,所得碼流將色彩空間轉換成RGB以適應ximagesink播放插件的媒體能力。最終,可以通過ximagesink播放器顯示出實時傳輸的視頻流,如圖3所示。
2.4 傳輸加密的設計
(1)AES加密算法的原理。

圖3 客戶端管道構成
文中系統使用分組長度和密鑰長度為128 bit的AES加密算法。信息被分成16組,按順序排列成4×4的狀態矩陣,該狀態矩陣就是AES算法中的數據最小單元。密鑰也同樣被表示為4×4的矩陣。AES算法對數據的加密實則是將輸入明文與密鑰由輪函數經Nr+1輪迭代來實現的。Nr由分組長度和密鑰長度共同決定,當分組長度和密鑰長度均為128時,Nr取10。在進行輪變換時,初始輪僅對明文和密鑰進行異或(或稱為輪密鑰加)。在之后的Nr-1輪變換中,需要一次進行字節置換,行變換,列變換以及輪密鑰加。在最后一輪變換中,省去了列變換,其余變換依次執行。每一輪所使用的輪密鑰由密鑰擴展函數所得[11]。整個加密過程如圖4所示。解密過程則是整個加密過程的逆過程。

圖4 AES算法流程圖
(2)使用AES加密算法實現視頻流加密。
為了使系統在獲得較強安全性的同時兼顧流媒體系統低時延的特性,決定對視頻流的加密處理置于視頻編碼完成后,進行RTP打包前。此時編碼后的視頻流輸出為NAL單元,而NAL單元頭部信息相對固定,且不包含視頻信息,并不存在加密的價值,因此可以僅對NAL負載單元進行完全加密[12]。
由于系統由Gstreamer流媒體框架搭建,因此需要以Gstreamer插件的形式來實現視頻流加解密。創建名為AesCip、AesDecip的Gstreamer插件[13]。AesCip插件的邏輯如圖5所示。
從輸入流得到一個NAL單元后,忽略NAL單元頭(即NAL單元的第一個字節),對第二個字節開始的NAL負載數據進行數據分組。以128bit為一個分組,若最后一個分組不足128bit,則使用一些無意義的附加數據(例如均取1)將其填滿[14]。最后調用AES加密函數處理每個數據分組,得到一個加密后的NAL單元。由于加密時將負載數據填充到了128bit的倍數,因此解密時需要識別出最后一個分組的附加數據并且將其刪除,以免對解碼視頻數據造成影響。調用AES解密函數處理每個分組,完成NAL負載解密[15]。在使用加解密插件時,需要在插件前后添加queue插件作為數據緩沖,以協調編碼、加密、RTP打包的處理速率。在文中的實驗環境中,測得視頻數據傳輸速率小于1M/s而使用1.2GHz的OMAP4460處理器進行AES分組加解密時,加解密速度均在2M/s以上,因此不會造成傳輸的阻塞,也不會產生很大的時延。

圖5 加解密插件程序流程圖
文中使用Gstreamer的管道調試工具gst-launch進行系統測試。測試時,以PandaBoardES開發板作為服務器,以PC端虛擬機為客戶端,服務器與客戶端處于同一局域網下,IP分別為10.10.101.80和10.10.101.169,服務端和客戶端均使用端口5000來傳遞視頻數據,使用端口5001和5002來收發RTCP包進行網絡流量控制和擁塞控制。
根據上文所述系統編寫服務器端和客戶端的shell腳本來調用調試工具。使用“!”管道符號連接起來,形成系統管道以供測試。測試時,先在客戶端運行client.sh,再在服務器端運行server.sh。服務器端和客戶端的shell腳本如下:
server.sh:
DEST=10.10.101.169
VOFFSET=0
VELEM="v4l2srcdevice=/dev/video0"
#VELEM="videotestsrcis-live=1"
VCAPS="video/x-raw-yuv,width=1280,height=720,framerate=30/1"
VSOURCE="$VELEM!queue!videorate!ffmpegcolorspace! $VCAPS"
VENC="x264enctune=zerolatencybyte-stream=truebitrate=300 !rtph264pay"
VCIP="queue!aescipkey-size=128key=000102030405060708090a0b0c0d0e0f!queue"
VRTPSINK="udpsinkport=5000host=$DESTts
-offset=$VOFFSETname=vrtpsink"
VRTCPSINK="udpsinkport=5001host=$DESTsync=falseasync=falsename=vrtcpsink"
VRTCPSRC="udpsrcport=5002name=vrtcpsrc"
gst-launch-vgstrtpbinname=rtpbin$VSOURCE! $VENC! $VCIP!rtpbin.send_rtp_sink_0
rtpbin.send_rtp_src_0 ! $VRTPSINK
rtpbin.send_rtcp_src_0 ! $VRTCPSINK$VRTCPSRC!rtpbin.recv_rtcp_sink_0
client.sh:
DEST=10.10.101.80
LATENCY=200
VCAPS="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264"
VDEC="rtph264depay!ffdec_h264"
VDECIP="queue!aesdecipkey-size=128key=000102030405060708090a0b0c0d0e0f!queue"
VSINK="ffmpegcolorspace!autovideosink"
gst-launch-vgstrtpbinname=rtpbinlatency=$LATENCYudpsrccaps=$VCAPSport=5000 !rtpbin.recv_rtp_sink_0 tpbin. ! $VDEC! $VDECIP! $VSINKudpsrcport=5001 !rtpbin.recv_rtcp_sink_0 tpbin.send_rtcp_src_0 !udpsinkport=5002host=$DESTsync=falseasync=false
測試結果如圖6所示。

圖6 客戶端接收到的視頻效果圖
測試結果表明,系統能夠穩定、實時、安全地進行視頻流傳輸,并且將傳輸時延控制在一定范圍內,符合系統的設計初衷。完成測試后,將上述管道封裝到client.c,server.c程序中,以供產品模式使用。
文中提出了一種基于Gstreamer流媒體框架,利用V4L2視頻驅動、H.264壓縮編碼技術、RTP流媒體傳輸協議實現的實時視頻流傳輸系統。并且使用AES加密算法對傳輸視頻流進行加密,在要求低時延的情況下完成了視頻流的安全傳輸。該系統可應用于視頻監控、視頻會議、在線教育等,具有廣闊的應用前景。
[1] 楊 澤,裴海龍.基于ARM與DSP的實時視頻傳輸系統[J].計算機工程與設計,2013,34(12):4184-4188.
[2] 畢厚杰.新一代視頻壓縮編碼標準—H.264/AVC[M].北京:人民郵電出版社,2005.
[3]IETFRTP:atransportprotocolforreal-timeapplications[S/OL].2003.http://www.ietf.org/rfc/rfc3550.txt.
[4]NIST.AdvancedEncryptionStandard(AES)[M].[s.l.]:FederalInformationProcessingStandardsPublication,2001.
[5]TI.OMAP4460multimediadevicedatamanual[M/OL].[s.l.]:TI.2012.http://www.ti.com/lit/ds/symlink/omap4460.pdf.
[6]PandaBoard.OMAP4460PandaboardESsystemreferencema-nual[M/OL].[s.l.]:PandaBoard.2011-09-29.http://pandaboard.org/sites/default/files/board_reference/ES/Panda_Board_Spec_DOC-21054_REV0_1.pdf.
[7]SchimekMH,DirksB,VerkuilH.VideoforLinuxtwoAPIspecification[S/OL].2006-02-03.http://www.linuxtv.org/downloads/legacy/video4linux/API/V4L2_API/spec-single/v4l2.html.
[8] 王彥麗,陳 明,陳 華,等.基于RTP/RTCP的數字視頻監控系統的設計與實現[J].計算機工程與科學,2009,31(3):58-60.
[9]TheGstreamerTeam.Gstreamerapplicationdevelopmentmanual[M/OL].[s.l.]:TheGstreamerTeam.2010.http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/manual.pdf.
[10]TheGstreamerTeam.GstreamerPlug-ins[M/OL].[s.l.]:TheGstreamerTeam.2010.http://gstreamer.freedesktop.org/documentation/plugins.html.
[11]DaemenJ,RijmenV.高級加密標準(AES)算法—Rijindael的設計[M].谷大武,徐勝波,譯.北京:清華大學出版社,2003.
[12] 姜 浩.基于H.264的實時視頻傳輸流密碼加密研究[D].南京:南京林業大學,2012.
[13]TheGstreamerTeam.Gstreamerpluginwriter’sguide[M/OL].[s.l.]:TheGstreamerTeam.2010.http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/pwg.pdf.
[14] 陳道敏,周金泉.加密技術在流媒體安全傳輸中的應用[J].網絡安全技術與應用,2004(11):53-55.
[15] 蔣建國,李 援,梁立偉.H.264視頻加密算法的研究及改進[J].電子學報,2007,35(9):1724-1727.
Design of Secure Video Stream Transmission System Based on Gstreamer
GONG Jian,WU Meng
(Nanjing University of Posts and Telecommunications,Nanjing 210003,China)
In this paper,a security video stream transmission system based on PandaBoard ES and Gstreamer platform is designed.In the system,V4L2 framework is used for collecting video source and H.264 compression coding technology is used for encoding the video stream.In terms of transmission,RTP is used to ensure good real-time performance.Last but not least,the AES encryption algorithm is also adopted to guarantee the security of the video data.The implementation of real-time video transmission system is comprehensively shown in this paper and through the analysis of the data acquired in the experiment.It is found that clients can receive the live video stream collected by the server timely,accurately and safely,which means that the secure video stream transmission system described in this paper is real-time,accurate,stable and secure.
real-time video transmission;Gstreamer;H.264 compression coding;RTP;AES encryption
2015-06-23
2015-09-25
時間:2016-02-18
國家“973”重點基礎研究發展計劃項目(2011CB302900);江蘇省高校自然科學研究重點項目(10KJA510035);南京市科技發展計劃重大項目(201103003)作者簡介:宮 健(1990-),男,碩士研究生,研究方向為無線通信與信號處理技術;吳 蒙,教授,研究方向為無線通信與信號處理技術。
http://www.cnki.net/kcms/detail/61.1450.TP.20160218.1636.066.html
TP302
A
1673-629X(2016)04-0177-05
10.3969/j.issn.1673-629X.2016.04.039