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

宮 健，吳 蒙

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

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

宮 健，吳 蒙

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

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

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

0 引 言

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

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

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

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

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

1 系統(tǒng)硬件設(shè)計(jì)

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

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

2 系統(tǒng)軟件設(shè)計(jì)

2.1 視頻的采集與編碼

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

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

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

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

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

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

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

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

2.2 實(shí)時(shí)視頻流網(wǎng)絡(luò)傳輸模塊設(shè)計(jì)

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

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

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

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

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

當(dāng)Element元件變得越來(lái)越多，數(shù)據(jù)管道越來(lái)越復(fù)雜時(shí)，Gstreamer允許將一組相互連接的元件組合成一個(gè)大的邏輯元件，稱(chēng)之為Bin(箱柜)，從而以對(duì)Bin進(jìn)行操作取代對(duì)單個(gè)Element元件的操作。

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

(1)服務(wù)器端管道。

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

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

(2)客戶端管道

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

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

2.4 傳輸加密的設(shè)計(jì)

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

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

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

圖4 AES算法流程圖

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語(yǔ)

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

[1] 楊 澤，裴海龍.基于ARM與DSP的實(shí)時(shí)視頻傳輸系統(tǒng)[J].計(jì)算機(jī)工程與設(shè)計(jì),2013,34(12):4184-4188.

[2] 畢厚杰.新一代視頻壓縮編碼標(biāo)準(zhǔn)—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)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與科學(xué)，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.高級(jí)加密標(biāo)準(zhǔn)(AES)算法—Rijindael的設(shè)計(jì)[M].谷大武，徐勝波，譯.北京：清華大學(xué)出版社，2003.

[12] 姜 浩.基于H.264的實(shí)時(shí)視頻傳輸流密碼加密研究[D].南京:南京林業(yè)大學(xué)，2012.

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

[14] 陳道敏，周金泉.加密技術(shù)在流媒體安全傳輸中的應(yīng)用[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用,2004(11):53-55.

[15] 蔣建國(guó)，李 援,梁立偉.H.264視頻加密算法的研究及改進(jìn)[J].電子學(xué)報(bào),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

時(shí)間：2016-02-18

國(guó)家“973”重點(diǎn)基礎(chǔ)研究發(fā)展計(jì)劃項(xiàng)目(2011CB302900)；江蘇省高校自然科學(xué)研究重點(diǎn)項(xiàng)目(10KJA510035)；南京市科技發(fā)展計(jì)劃重大項(xiàng)目(201103003)作者簡(jiǎn)介：宮 健(1990-),男，碩士研究生，研究方向?yàn)闊o(wú)線通信與信號(hào)處理技術(shù)；吳 蒙，教授，研究方向?yàn)闊o(wú)線通信與信號(hào)處理技術(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