基于Gstreamer的安全視頻流傳輸系統(tǒng)的實現(xiàn)

宮 健，吳 蒙

(南京郵電大學，江蘇 南京 210003)

基于Gstreamer的安全視頻流傳輸系統(tǒng)的實現(xiàn)

宮 健，吳 蒙

(南京郵電大學，江蘇 南京 210003)

文中設計并實現(xiàn)了一種基于PandaBoard ES硬件平臺和Gstreamer開發(fā)框架的安全視頻流傳輸系統(tǒng)。在系統(tǒng)中使用了V4L2視頻采集框架、H.264壓縮編碼技術(shù)、RTP流媒體傳輸協(xié)議實現(xiàn)了端到端的視頻流實時傳輸，并且采用AES加密算法針對實時視頻流進行加密，保證了視頻數(shù)據(jù)的安全性。文中全面展示了實時視頻系統(tǒng)的搭建過程，并且通過Gstreamer管道測試驗證了該系統(tǒng)方案的可行性。測試結(jié)果表明,系統(tǒng)能夠?qū)崟r、準確、穩(wěn)定、安全地將現(xiàn)場采集視頻流信息顯示到客戶端,滿足了遠程視頻監(jiān)控系統(tǒng)的低時延、高安全的需求。

實時視頻傳輸；Gstreamer；H264壓縮編碼；RTP；AES加密

0 引 言

近年來，隨著互聯(lián)網(wǎng)的廣泛普及和多媒體技術(shù)的飛速發(fā)展，人們對基于網(wǎng)絡的實時視頻服務需求不斷增長。典型的網(wǎng)絡實時視頻應用包括交互式視頻服務、視頻電話、遠程教學以及遠程醫(yī)療等。而嵌入式媒體平臺由于體積小巧、功耗低、成本低廉的優(yōu)點，成為了遠程視頻傳輸系統(tǒng)的良好載體[1]。

H.264作為繼MPEG4之后的新一代數(shù)字視頻編解碼技術(shù)，對實時視頻流傳輸有很好的支持，在能夠還原出高質(zhì)量圖像的基礎上，不但具備可觀的壓縮比，較低的工作時延，還提供了糾錯檢錯機制[2]。

實時傳輸協(xié)議(Real-time Transport Protocol，RTP)是一種網(wǎng)絡傳輸協(xié)議，負責對流媒體數(shù)據(jù)進行封裝，提供了時間信息和同步信息，實現(xiàn)了流媒體數(shù)據(jù)端對端的實時傳送。但RTP并不保證服務質(zhì)量，服務質(zhì)量交由與其配套的實時傳輸控制協(xié)議(Real-time Transport Control Protocol,RTCP)來控制[3]。RTP和RTCP均采用UDP協(xié)議發(fā)送數(shù)據(jù)包。

AES是美國國家標準技術(shù)研究所(NIST)取代DES的新一代加密標準[4],是一種對稱分組密碼體制，使用Rijindael作為核心算法，具有強安全性、高性能、高效率、易用靈活等優(yōu)點。

文中使用了TI公司的嵌入式平臺PandaBoard ES作為硬件平臺，結(jié)合了H.264編碼技術(shù)和RTP協(xié)議，實現(xiàn)了視頻流端到端的實時傳輸。并以此為基礎，對傳輸?shù)囊曨l流進行了AES加密，保證了視頻流數(shù)據(jù)的安全性。

1 系統(tǒng)硬件設計

文中所述系統(tǒng)搭建在PandaBoard ES系列開發(fā)板上。PandaBoard ES采用OMAP4460[5]作為核心處理器。OMAP4460使用了雙核Cortex-A9對稱架構(gòu)，其主頻可達1.2 GHz，并且內(nèi)置了圖形加速器PowerVR SGX540，是一款功能強悍的高性能處理器，可提供對稱多處理(SMP)性能以及豐富的多媒體與3D圖形支持。PandaBoard ES支持包括HDMI v1.3、DVI-D在內(nèi)的多種媒體接口，搭載了IVA3多媒體加速器，支持全高清、1080p 30 fps多標準高清視頻的錄制與播放[6]。

文中所使用的e-CAM51_44x攝像頭是專為搭載OMAP4系列處理器PandaBoard開發(fā)板設計的相機子板。其搭載了具有500萬像素的自動聚焦圖像傳感器OV5640，可以使用V4L2直接驅(qū)動，同時PandaBoard提供的100 M以太網(wǎng)口也使得遠端傳輸視頻成為了可能。

2 系統(tǒng)軟件設計

2.1 視頻的采集與編碼

(1)V4L2實現(xiàn)視頻采集。

文中系統(tǒng)使用V4L2框架來實現(xiàn)視頻源的采集。V4L2(Video For Linux Two)是Linux系統(tǒng)提供給應用程序訪問音、視頻驅(qū)動的統(tǒng)一接口，在嵌入式多媒體終端中有著廣泛的應用[7]。

系統(tǒng)采集的視頻幀格式為YUV，大小為1 080*720，因此在設置視頻采集參數(shù)時需指定幀格式為V4L2_PIX_FMT_YUYV，幀高1 080，幀寬720。此外，視頻采集流的幀率V4L2_CAP_TIMEPERFRAME設置成30 fps。

(2)使用H.264進行視頻編碼。

完成視頻采集后，需要將采集的碼流進行壓縮編碼以適應網(wǎng)絡傳輸。文中選用H.264編碼，在獲得較高視頻壓縮比的同時，也能夠保證實時視頻流的傳輸質(zhì)量。

H.264協(xié)議中定義了三種幀：I幀、P幀和B幀[2]。I幀為幀內(nèi)編碼幀,其編碼不依賴于已經(jīng)編碼的圖像數(shù)據(jù)。P幀為前向預測幀,記錄的是該幀與前一個I幀(或P幀)的差別。B幀為雙向預測幀,記錄的是該幀和前后幀的差別。I幀與B幀編碼時都需要根據(jù)已編碼的幀(即參考幀)進行運動估計。

在進行H.264壓縮編碼時，存在兩種核心算法：一種是幀內(nèi)壓縮編碼(也稱為空間壓縮)，用于生成I幀。編碼器在實現(xiàn)時會首先選擇相應的幀內(nèi)預測模式進行幀內(nèi)預測，隨后對實際值和預測值之間的差值進行變換、量化和熵編碼,同時將編碼后的碼流經(jīng)過反量化和反變換之后重建預測殘差圖像；然后再與預測值相加以得出重構(gòu)幀；最后將得出的結(jié)果經(jīng)過去塊濾波器平滑后送入幀緩存。另一種是幀間壓縮編碼，用于生成B幀和P幀。編碼器在實現(xiàn)時，會將輸入的圖像塊首先在參考幀中進行運動估計,以得到運動矢量。運動估計后的殘差圖像經(jīng)整數(shù)變換、量化和熵編碼后與運動矢量一起送入信道傳輸。同時將另一路碼流以相同的方式重建后經(jīng)去塊濾波再送入幀緩存作為下一幀編碼的參考圖像。當壓縮后的碼流進入解碼器時，解碼器會先判斷。該幀若是幀內(nèi)編碼所得，則直接進行反量化、反變換加以重建；若是幀間編碼所得，需要根據(jù)幀緩存中的參考圖像進行運動補償再疊加補償前的殘缺圖像，從而還原出真實圖像幀。

由于系統(tǒng)的實時性要求很高，文中使用了支持并行處理的X264編碼器對視頻流進行H.264編碼，并且為了使系統(tǒng)獲得更高的性能，訂制了X264編碼框架所使用的參數(shù)。將X264的profile參數(shù)設定為baseline(基本檔次)以適應視頻實時通信應用。設置比特率參數(shù)bitrate為300，設置tune為zerolatency。編碼器會自動工作在低時延狀態(tài)，禁用一些會增加時延的功能如sliced-threads(開啟基于分片的線程)、sync-lookahead(啟用線程預測的幀緩存)等。

2.2 實時視頻流網(wǎng)絡傳輸模塊設計

文中系統(tǒng)使用RTP協(xié)議來完成端到端的視頻傳輸，并且配合使用RTCP協(xié)議來完成網(wǎng)絡流量控制和擁塞控制，保證網(wǎng)絡傳輸?shù)馁|(zhì)量[8]。

根據(jù)上文所述，當服務器端視頻流完成編碼后，H.264編碼器會將完成的VCL(視頻編碼層)數(shù)據(jù)封裝到NAL(網(wǎng)絡抽象層)單元中以適應網(wǎng)絡傳輸。RTP協(xié)議會對這些NAL單元進行再次打包封裝，寫入時間戳和序列號等信息用以在接收端恢復準確的時間順序。之后放入到RTP發(fā)送緩沖區(qū)交由UDP處理，封裝成UDP數(shù)據(jù)包發(fā)送至網(wǎng)絡。客戶端接收到數(shù)據(jù)包時先進行UDP解包，得到RTP數(shù)據(jù)包，根據(jù)RTP包頭的同步信息進行重排序，再對RTP包的負載進行解析。與此同時，使用RTCP協(xié)議分析當前網(wǎng)絡狀態(tài)。在服務器端，RTCP會周期性的發(fā)送SR(發(fā)送方報告)包，接收RR(接收方報告包)，客戶端則周期性接收SR包，反饋RR包。服務器端根據(jù)發(fā)送的SR包和接收的RR包分析出丟包率，從而動態(tài)調(diào)節(jié)RTP的發(fā)包速率(可以通過調(diào)節(jié)編碼的速率來實現(xiàn))，以適應當前網(wǎng)絡狀況。整體工作流程如圖1所示。

2.3 基于Gstreamer的視頻傳輸系統(tǒng)實現(xiàn)

文中使用了Gstreamer[9-10]流媒體開發(fā)框架設計實現(xiàn)了實時視頻傳輸系統(tǒng)。Gstreamer是一個基于插件和管道結(jié)構(gòu)的媒體開發(fā)框架。Gstreamer流媒體框架通過基本元素構(gòu)件Element相連接組成管道。Element元件根據(jù)功能又可以分為Src(數(shù)據(jù)源)元件、Filter(過濾器)元件、Sink(接收器)元件。而元件內(nèi)的數(shù)據(jù)流傳輸又以Pad(襯墊)的形式實現(xiàn)，可分為Src Pad(輸入襯墊)和Sink Pad(輸出襯墊)。

圖1 視頻流網(wǎng)絡傳輸模塊流程圖

當Element元件變得越來越多，數(shù)據(jù)管道越來越復雜時，Gstreamer允許將一組相互連接的元件組合成一個大的邏輯元件，稱之為Bin(箱柜)，從而以對Bin進行操作取代對單個Element元件的操作。

文中系統(tǒng)正是在Gstreamer插件和管道的基礎上，由視頻流管道構(gòu)成。

(1)服務器端管道。

服務器端的視頻數(shù)據(jù)流開始于V4L2從攝像頭采集到的視頻數(shù)據(jù)。使用數(shù)據(jù)隊列插件queue對采集到的視頻數(shù)據(jù)流進行緩沖，經(jīng)緩沖的數(shù)據(jù)再通過videorate插件調(diào)整幀率以得到穩(wěn)定的、適合播放的視頻輸入源。之后調(diào)用X264enc編碼器插件對視頻輸入流進行H264編碼。完成編碼后的碼流開始進入RTP處理流程。首先經(jīng)過rtph264pay插件進行RTP打包，然后通過rtpbin箱柜。rtpbin箱柜是一個將rtpsession、rtpssrcdemux、rtpjitterbuffer、rtpptdemux組件整合到一個組件的箱柜，用以控制rtp會話，并將數(shù)據(jù)包以RTP協(xié)議封裝(或解封裝)，然后交由udpsink插件以UDP包的形式發(fā)送至客戶端端口。同時，規(guī)定另外兩個端口用于發(fā)送和接收RTCP包，rtpbin會根據(jù)反饋的RTCP包，進行流量控制和擁塞控制，如圖2所示。

圖2 服務器端管道構(gòu)成

(2)客戶端管道

客戶端用于監(jiān)聽數(shù)據(jù)的端口收到了服務器端的數(shù)據(jù)流，經(jīng)由udpsrc插件接收到了UDP數(shù)據(jù)包，交由rtpbin處理。同時，規(guī)定另外兩個端口用于發(fā)送和接收RTCP包配合rtpbin進行流量控制和擁塞控制。rtpbin中的rtpjitterbuffer組件能夠緩沖網(wǎng)絡抖動并且將數(shù)據(jù)包重新排序，將順序正確的RTP包交由rtph264depay插件以將RTP包解包為NAL單元負載流。

使用高性能解碼器ffmpeg對NAL單元負載流進行H.264解碼，所得碼流將色彩空間轉(zhuǎn)換成RGB以適應ximagesink播放插件的媒體能力。最終，可以通過ximagesink播放器顯示出實時傳輸?shù)囊曨l流，如圖3所示。

2.4 傳輸加密的設計

(1)AES加密算法的原理。

圖3 客戶端管道構(gòu)成

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

圖4 AES算法流程圖

(2)使用AES加密算法實現(xiàn)視頻流加密。

為了使系統(tǒng)在獲得較強安全性的同時兼顧流媒體系統(tǒng)低時延的特性，決定對視頻流的加密處理置于視頻編碼完成后，進行RTP打包前。此時編碼后的視頻流輸出為NAL單元，而NAL單元頭部信息相對固定，且不包含視頻信息，并不存在加密的價值，因此可以僅對NAL負載單元進行完全加密[12]。

由于系統(tǒng)由Gstreamer流媒體框架搭建，因此需要以Gstreamer插件的形式來實現(xiàn)視頻流加解密。創(chuàng)建名為AesCip、AesDecip的Gstreamer插件[13]。AesCip插件的邏輯如圖5所示。

從輸入流得到一個NAL單元后，忽略NAL單元頭(即NAL單元的第一個字節(jié))，對第二個字節(jié)開始的NAL負載數(shù)據(jù)進行數(shù)據(jù)分組。以128bit為一個分組，若最后一個分組不足128bit，則使用一些無意義的附加數(shù)據(jù)(例如均取1)將其填滿[14]。最后調(diào)用AES加密函數(shù)處理每個數(shù)據(jù)分組，得到一個加密后的NAL單元。由于加密時將負載數(shù)據(jù)填充到了128bit的倍數(shù)，因此解密時需要識別出最后一個分組的附加數(shù)據(jù)并且將其刪除，以免對解碼視頻數(shù)據(jù)造成影響。調(diào)用AES解密函數(shù)處理每個分組，完成NAL負載解密[15]。在使用加解密插件時，需要在插件前后添加queue插件作為數(shù)據(jù)緩沖，以協(xié)調(diào)編碼、加密、RTP打包的處理速率。在文中的實驗環(huán)境中，測得視頻數(shù)據(jù)傳輸速率小于1M/s而使用1.2GHz的OMAP4460處理器進行AES分組加解密時，加解密速度均在2M/s以上，因此不會造成傳輸?shù)淖枞膊粫a(chǎn)生很大的時延。

圖5 加解密插件程序流程圖

3 系統(tǒng)測試分析

文中使用Gstreamer的管道調(diào)試工具gst-launch進行系統(tǒng)測試。測試時，以PandaBoardES開發(fā)板作為服務器，以PC端虛擬機為客戶端，服務器與客戶端處于同一局域網(wǎng)下，IP分別為10.10.101.80和10.10.101.169,服務端和客戶端均使用端口5000來傳遞視頻數(shù)據(jù)，使用端口5001和5002來收發(fā)RTCP包進行網(wǎng)絡流量控制和擁塞控制。

根據(jù)上文所述系統(tǒng)編寫服務器端和客戶端的shell腳本來調(diào)用調(diào)試工具。使用“！”管道符號連接起來，形成系統(tǒng)管道以供測試。測試時，先在客戶端運行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

測試結(jié)果如圖6所示。

圖6 客戶端接收到的視頻效果圖

測試結(jié)果表明，系統(tǒng)能夠穩(wěn)定、實時、安全地進行視頻流傳輸，并且將傳輸時延控制在一定范圍內(nèi)，符合系統(tǒng)的設計初衷。完成測試后，將上述管道封裝到client.c,server.c程序中，以供產(chǎn)品模式使用。

4 結(jié)束語

文中提出了一種基于Gstreamer流媒體框架，利用V4L2視頻驅(qū)動、H.264壓縮編碼技術(shù)、RTP流媒體傳輸協(xié)議實現(xiàn)的實時視頻流傳輸系統(tǒng)。并且使用AES加密算法對傳輸視頻流進行加密，在要求低時延的情況下完成了視頻流的安全傳輸。該系統(tǒng)可應用于視頻監(jiān)控、視頻會議、在線教育等，具有廣闊的應用前景。

[1] 楊 澤，裴海龍.基于ARM與DSP的實時視頻傳輸系統(tǒng)[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的數(shù)字視頻監(jiān)控系統(tǒng)的設計與實現(xiàn)[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].南京:南京林業(yè)大學，2012.

[13]TheGstreamerTeam.Gstreamerpluginwriter’sguide[M/OL].[s.l.]:TheGstreamerTeam.2010.http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/pwg.pdf.

[14] 陳道敏，周金泉.加密技術(shù)在流媒體安全傳輸中的應用[J].網(wǎng)絡安全技術(shù)與應用,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”重點基礎研究發(fā)展計劃項目(2011CB302900)；江蘇省高校自然科學研究重點項目(10KJA510035)；南京市科技發(fā)展計劃重大項目(201103003)作者簡介：宮 健(1990-),男，碩士研究生，研究方向為無線通信與信號處理技術(shù)；吳 蒙，教授，研究方向為無線通信與信號處理技術(shù)。

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