一種保證初始數(shù)據(jù)完整性的實(shí)時(shí)視頻流分發(fā)插件①

張凱

(蘇州科達(dá)科技股份有限公司 上海研發(fā)中心,上海 201103)

一種保證初始數(shù)據(jù)完整性的實(shí)時(shí)視頻流分發(fā)插件①

張凱

(蘇州科達(dá)科技股份有限公司 上海研發(fā)中心,上海 201103)

在視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)中進(jìn)行實(shí)時(shí)監(jiān)控時(shí),如果監(jiān)控客戶端收到的初始視頻數(shù)據(jù)不完整會(huì)出現(xiàn)初始播放畫面花屏的問(wèn)題.基于開(kāi)源多媒體框架GStreamer,針對(duì)H.264編碼標(biāo)準(zhǔn),設(shè)計(jì)并實(shí)現(xiàn)了一種實(shí)時(shí)視頻流分發(fā)插件.該插件使用隨機(jī)創(chuàng)建的請(qǐng)求型source襯墊用于視頻數(shù)據(jù)的分發(fā),并通過(guò)緩存當(dāng)前IDR幀組的方法確保發(fā)送初始視頻數(shù)據(jù)的完整性.該插件可應(yīng)用于流媒體服務(wù)器當(dāng)中,解決實(shí)時(shí)監(jiān)控時(shí)初始畫面花屏的問(wèn)題.實(shí)驗(yàn)結(jié)果表明,應(yīng)用該插件的流媒體服務(wù)器能夠高效分發(fā)實(shí)時(shí)視頻數(shù)據(jù)并保證初始播放畫面完整,對(duì)提升實(shí)時(shí)監(jiān)控效果有著明顯的作用.

視頻監(jiān)控;流媒體服務(wù)器;GStreamer框架;H.264標(biāo)準(zhǔn);IDR幀;RTP協(xié)議

視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)中使用IPC(IP Camera網(wǎng)絡(luò)攝像機(jī))作為監(jiān)控前端采集實(shí)時(shí)視頻流,通過(guò)流媒體服務(wù)器分發(fā)到多個(gè)監(jiān)控客戶端(以下簡(jiǎn)稱客戶端)進(jìn)行實(shí)時(shí)視頻監(jiān)控.流媒體服務(wù)器的這種工作模式呈現(xiàn)“一進(jìn)多出”的拓?fù)湫螒B(tài).

高清視頻編碼標(biāo)準(zhǔn)(如H.264[1])使用幀間圖像數(shù)據(jù)壓縮技術(shù).由于實(shí)時(shí)視頻流訪問(wèn)的隨機(jī)性,客戶端獲取到的初始視頻幀(第一個(gè)視頻幀)可能需要參考之前的幀進(jìn)行解碼,這會(huì)導(dǎo)致客戶端由于接收的初始視頻數(shù)據(jù)不完整出現(xiàn)初始播放畫面花屏現(xiàn)象,影響了實(shí)時(shí)監(jiān)控效果.

為解決這一問(wèn)題,需要在視頻流分發(fā)側(cè)保證發(fā)送到客戶端的每一路視頻流的初始視頻數(shù)據(jù)是完整的.

在視頻流分發(fā)側(cè)使用緩存數(shù)據(jù)保證所發(fā)送數(shù)據(jù)完整性是目前業(yè)內(nèi)常用方式.內(nèi)容分發(fā)網(wǎng)絡(luò) CDN (Content Delivery Network)是使用數(shù)據(jù)緩存方式的代表[2].在CDN中,使用緩存代理服務(wù)器緩存流媒體服務(wù)器的內(nèi)容,客戶端從緩存代理服務(wù)器上獲取流媒體內(nèi)容.

CDN在提升流媒體服務(wù)響應(yīng)速度,媒體流分發(fā)容量的同時(shí),也對(duì)網(wǎng)絡(luò)傳輸服務(wù)質(zhì)量提出了很高的要求.在CDN中傳輸實(shí)時(shí)視頻流時(shí),緩存代理服務(wù)器和流媒體服務(wù)器之間需要實(shí)時(shí)同步緩存數(shù)據(jù).若緩存代理服務(wù)器和流媒體服務(wù)器之間的網(wǎng)絡(luò)質(zhì)量不佳,實(shí)時(shí)監(jiān)控效果會(huì)受到較大影響.

本文提出了在流媒體服務(wù)器上通過(guò)實(shí)時(shí)視頻流分發(fā)插件緩存當(dāng)前視頻數(shù)據(jù)以保證初始視頻數(shù)據(jù)完整性的方法,針對(duì)H.264編碼標(biāo)準(zhǔn),基于GStreamer框架[3,4]設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)應(yīng)用于流媒體服務(wù)器中的實(shí)時(shí)視頻流分發(fā)插件.相比較CDN而言,本文描述的流媒體服務(wù)器不需要緩存代理服務(wù)器就能通過(guò)分發(fā)插件保證所分發(fā)初始視頻數(shù)據(jù)的完整性,不再產(chǎn)生流媒體服務(wù)器與緩存代理服務(wù)器之間的通訊開(kāi)銷.

本文描述了分發(fā)插件的設(shè)計(jì)與實(shí)現(xiàn)方法并給出相關(guān)實(shí)驗(yàn)結(jié)果.

1 相關(guān)定義

1.1 GStreamer中相關(guān)定義

GStreamer框架基于插件(plugins).GStreamer中的插件是一段可以加載的代碼,常常以動(dòng)態(tài)鏈接庫(kù)的形式存在.一個(gè)GStreamer插件中可包含一個(gè)或多個(gè)元件(Element)[5].

元件是GStreamer中最重要的概念,見(jiàn)定義1.

定義1.元件:GStreamer中,元件是構(gòu)建一個(gè)媒體管道的基本塊,GStreamer中的元件都繼承自GstElement對(duì)象.

多媒體應(yīng)用程序可以創(chuàng)建若干個(gè)元件(elements)連接在一起,從而構(gòu)成一個(gè)管道(pipeline)來(lái)完成一個(gè)媒體處理任務(wù).GStreamer中的管道見(jiàn)定義2.

定義2.管道:管道是一種容器元件,可以向管道中添加元件從而將一組存在鏈接的元件組合成一個(gè)大的邏輯元件.管道可以操作包含在其自身內(nèi)部的所有元件.

管道中的元件需要建立鏈接關(guān)系,襯墊(Pads)在GStreamer中被用于元件之間的鏈接,從而讓數(shù)據(jù)流能在管道中流動(dòng).襯墊的定義見(jiàn)定義3.

定義3.襯墊:襯墊是元件之間的接口,元件之間的數(shù)據(jù)交互依靠襯墊來(lái)完成.襯墊能夠限制數(shù)據(jù)流的通過(guò),只有兩個(gè)元件鏈接在一起的襯墊允許通過(guò)的數(shù)據(jù)類型一致時(shí),這兩個(gè)元件才可交換數(shù)據(jù).

一個(gè)襯墊很像一個(gè)物理設(shè)備上的接口,如電視機(jī)上的HDMI輸入接口和機(jī)頂盒上的HDMI輸出接口.正因?yàn)殡娨暀C(jī)和機(jī)頂盒都有相同類型的接口,才可以使用數(shù)據(jù)線連接起來(lái)完成媒體流的播放.

根據(jù)數(shù)據(jù)流向,襯墊被分為兩種類型:source襯墊與sink襯墊.數(shù)據(jù)向元件之外流出可以通過(guò)一個(gè)或多個(gè)source襯墊,元件接受數(shù)據(jù)通過(guò)一個(gè)或多個(gè)sink襯墊來(lái)完成.在一個(gè)管道中,數(shù)據(jù)流從一個(gè)元件的source襯墊流到另一個(gè)元件的sink襯墊.

根據(jù)生命周期,襯墊分為永久型(always)、隨機(jī)型(sometimes)、請(qǐng)求型(request)三種類型.永久型襯墊在元件創(chuàng)建時(shí)就存在,并一直存在直到所屬元件銷毀.隨機(jī)型襯墊在某種特定條件觸發(fā)后才創(chuàng)建并存在.請(qǐng)求型襯墊只在應(yīng)用程序明確發(fā)出請(qǐng)求時(shí)才創(chuàng)建并存在.

使用元件,管道和襯墊這些GStreamer基本元素可以構(gòu)建豐富的多媒體應(yīng)用程序.

1.2 IDR幀組

視頻編碼中,每一個(gè)圖像幀代表一幅靜止的圖像.實(shí)際壓縮時(shí),會(huì)采取各種算法減少數(shù)據(jù)的容量[6].

I幀表示關(guān)鍵幀,可理解為這一幀畫面的完整保留,解碼時(shí)只需要本幀數(shù)據(jù)就可以完成.P幀表示的是這一幀跟之前一個(gè)關(guān)鍵幀(或P幀)的差別,解碼時(shí)需要用之前緩存的關(guān)鍵幀(或P幀)疊加上本幀定義的差別,生成最終畫面.B幀是雙向差別幀,B幀記錄本幀與前后幀的差別.要解碼B幀,不僅要取得之前的緩存畫面,還要解碼之后的畫面,通過(guò)前后畫面與本幀數(shù)據(jù)的疊加獲得最終畫面.

在H.264編碼中,I幀不用參考任何幀,但是之后的P幀和B幀有可能參考這個(gè)I幀之前的幀.為區(qū)分首個(gè)I幀和其他I幀,把首個(gè)I幀稱為IDR(Instantaneous Decoding Refresh即時(shí)解碼刷新)幀[1].由IDR幀開(kāi)始,重新開(kāi)始編解碼一個(gè)新的幀序列.IDR幀之后的所有幀都不會(huì)引用該IDR幀之前幀的內(nèi)容.由此可知,IDR幀阻斷了誤差的積累,提供了隨機(jī)訪問(wèn)性,播放器可以從視頻流中任意一個(gè)IDR幀播放而不會(huì)導(dǎo)致花屏.

考察幀序列(下標(biāo)表示幀的顯示順序):I1P4B2B3P7B5B6I8P11B9B10P14B11B12.這里I1和I8就是IDR幀,因?yàn)槠渲蟮膸恍枰邕^(guò)該幀去參考之前的幀.

定義4定義了IDR幀組的概念.

定義4 IDR幀組 視頻流中一個(gè)IDR幀和其之后,下一個(gè)IDR幀之前的幀組成的集合稱為IDR幀組.

參考幀序列:I1P4B2B3P7B5B6I8P11B9B10P14B11B12.{I1,P4,B2,B3},{I1,P4,B2,B3,P7,B5,B6},{I8, P11,B9,B10}都可被稱為IDR幀組.

2 基于GStreamer的流媒體服務(wù)器架構(gòu)

流媒體服務(wù)器是視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)的核心部分.流媒體服務(wù)器獲取所請(qǐng)求IPC的實(shí)時(shí)視頻流,并將這一路視頻流分發(fā)到各個(gè)請(qǐng)求的客戶端[2].

基于GStreamer框架,僅用于實(shí)時(shí)視頻瀏覽的流媒體服務(wù)器架構(gòu)如圖1所示.本文約定IPC生成的視頻流格式為H.264編碼格式,客戶端與流媒體服務(wù)器之間,流媒體服務(wù)器與IPC之間都使用RTSP[7]作為控制協(xié)議,使用RTP[8]作為視頻數(shù)據(jù)傳輸協(xié)議.為方便描述,本文約定一個(gè)IPC只提供一路實(shí)時(shí)視頻流,并使用ES流(Elementary Stream,基本流)傳輸.

圖1 基于GStreamer框架的流媒體服務(wù)器架構(gòu)

圖1 的流媒體服務(wù)器中,clientproxy元件接收來(lái)自客戶端的實(shí)時(shí)瀏覽請(qǐng)求建立RTSP會(huì)話,并對(duì)RTSP會(huì)話中所請(qǐng)求的IPC建立對(duì)應(yīng)的數(shù)據(jù)分發(fā)管道.該數(shù)據(jù)分發(fā)管道為定義2所定義的GStreamer管道,包含一個(gè)ipcsrc元件,一個(gè) streamdispatcher元件和若干個(gè)clientsink元件.Clientsink元件是隨機(jī)產(chǎn)生的,每建立一個(gè)對(duì)該IPC請(qǐng)求的RTSP會(huì)話,clientproxy元件就在該數(shù)據(jù)分發(fā)管道中創(chuàng)建一個(gè)clientsink元件與其對(duì)應(yīng).

數(shù)據(jù)分發(fā)管道中的ipcsrc元件使用RTSP協(xié)議向所請(qǐng)求IPC獲取實(shí)時(shí)視頻流,獲取的實(shí)時(shí)視頻流使用RTP協(xié)議由IPC發(fā)送到ipcsrc元件.Ipcsrc元件收到承載實(shí)時(shí)視頻流的RTP包后,傳遞到streamdispatcher元件進(jìn)行分發(fā).Streamdispatcher元件將收到的RTP包分別傳遞給管道中每個(gè)clientsink元件.

管道中每個(gè)clientsink元件包含了其對(duì)應(yīng)RTSP會(huì)話的會(huì)話參數(shù)(傳輸協(xié)議,地址端口等信息),clientsink元件將streamdispatcher元件分發(fā)的RTP包根據(jù)會(huì)話參數(shù)發(fā)送到客戶端.

以圖1為例,clientproxy元件收到客戶端1對(duì)IPC1的實(shí)時(shí)視頻流會(huì)話請(qǐng)求后建立RTSP會(huì)話1,并建立名為管道1的數(shù)據(jù)分發(fā)管道.管道1中包含一個(gè)ipcsrc元件ipcsrc1,一個(gè)streamdispatcher元件streamdispatcher1和一個(gè)clientsink元件clientsink1(包含RTSP會(huì)話1的會(huì)話參數(shù)).ipcsrc1使用RTSP協(xié)議向IPC1請(qǐng)求實(shí)時(shí)視頻流后,承載視頻流的 RTP包經(jīng)“ipcsrc1→streamdispatcher1→clientsink1”的路徑傳遞后發(fā)送到客戶端1.此后若clientproxy元件又建立客戶端2對(duì)IPC1請(qǐng)求的RTSP會(huì)話2,則在管道1中再創(chuàng)建clientsink元件clientsink2(包含RTSP會(huì)話2的會(huì)話參數(shù)),承載視頻流的 RTP包經(jīng)“ipcsrc1→streamdispatcher1→clientsink2”的路徑傳遞后發(fā)送到客戶端2.

圖1中管道的生命周期依賴于請(qǐng)求其對(duì)應(yīng)IPC的客戶端RTSP會(huì)話數(shù)目:當(dāng)會(huì)話數(shù)目大于0時(shí),管道被創(chuàng)建clientproxy元件;當(dāng)會(huì)話數(shù)目等于0時(shí),管道被clientproxy元件銷毀.

streamdispatcher元件是數(shù)據(jù)分發(fā)管道中的分發(fā)控制中樞,不僅將數(shù)據(jù)分發(fā)給clientsink元件,還保證發(fā)送 給 clientsink 元 件 的 初 始 幀 為 IDR 幀 . streamdispatcher元件的設(shè)計(jì)與實(shí)現(xiàn)是本文的重點(diǎn),下一節(jié)將詳細(xì)介紹streamdispatcher元件的設(shè)計(jì)與實(shí)現(xiàn).

3 實(shí)時(shí)視頻流分發(fā)插件設(shè)計(jì)與實(shí)現(xiàn)

3.1 設(shè)計(jì)思想

將IPC發(fā)送的實(shí)時(shí)視頻流視為一個(gè)幀序列.為確保發(fā)送到客戶端的初始幀為IDR幀,streamdispatcher元件需緩存當(dāng)前幀參考的IDR幀組(當(dāng)前幀參考的IDR幀及當(dāng)前幀與IDR幀之間的其它幀).Streamdispatcher元件在分發(fā)數(shù)據(jù)時(shí)總是先發(fā)送緩存的當(dāng)前IDR幀組,再發(fā)送當(dāng)前幀.這種工作方式可由圖2示意.

圖2中t1時(shí)刻,請(qǐng)求IPC實(shí)時(shí)視頻流的RTSP會(huì)話1建立,與之對(duì)應(yīng)的 clientsink元件也隨之創(chuàng)建. streamdispatcher元件此時(shí)收到IPC發(fā)送的當(dāng)前幀為SLICE1m(非IDR幀,且IDR1與SLICE1m之間無(wú)IDR幀).因?yàn)樵趖1時(shí)刻之前,streamdispatcher元件中已經(jīng)緩存了IDR1及IDR1至SLICE1m之間所有幀的IDR幀組,所以在t1時(shí)刻streamdispatcher元件首先發(fā)送緩存的IDR幀組,再發(fā)送SLICE1m幀給對(duì)應(yīng)RTSP會(huì)話1的clientsink元件.對(duì)應(yīng)RTSP會(huì)話1的clientsink元件收到初始幀為IDR1.同理在t2時(shí)刻,streamdispatcher元件中緩存的是IDR2及IDR2至SLICE2n之間(IDR2與SLICE2n之間無(wú)IDR幀)所有幀的IDR幀組,對(duì)應(yīng)RTSP會(huì)話2的clientsink元件收到的初始幀為IDR2.

圖2 streamdispatcher元件工作原理

Clientproxy元件建立RTSP會(huì)話時(shí)會(huì)創(chuàng)建對(duì)應(yīng)的clientsink元件,然后向streamdispatcher元件申請(qǐng)創(chuàng)建一個(gè)請(qǐng)求型source襯墊,并將此襯墊與clientsink元件的sink襯墊進(jìn)行鏈接.當(dāng)streamdispatcher元件在接收視頻流數(shù)據(jù)后,通過(guò)已創(chuàng)建的請(qǐng)求型source襯墊將數(shù)據(jù)推送到 clientsink元件.Ipcsrc、clientproxy和clientsink之間的襯墊鏈接關(guān)系如圖3所示.

圖3 管道中元件的襯墊鏈接關(guān)系

3.2 IDR幀識(shí)別方法

ES流中,IPC將H.264視頻編碼后的NALU (Network Abstract Layer Unit)封裝在RTP包中.NALU的首字節(jié)定義如圖4所示.

圖4 NALU的首字節(jié)定義

其中F為1個(gè)比特,在規(guī)范中規(guī)定為0.NRI為2個(gè)比特,用于表示NALU的優(yōu)先級(jí).Type為5個(gè)比特,表示NALU的類型.若NALU類型為5,則表示該NALU為IDR圖像,其對(duì)應(yīng)的幀為IDR幀.

RTP在對(duì)NALU封包時(shí),會(huì)使用單一NAL單元模式,組合封包模式,分片封包模式這三種模式中的一種.在實(shí)際運(yùn)行中,應(yīng)根據(jù)視頻流的封包模式判斷RTP載荷的NALU類型是否為IDR幀類型.

以分片封包模式為例,若RTP包載荷的首字節(jié)中Type為28,表示為FU-A類型的分片單元.此時(shí)應(yīng)判斷該RTP包是否為第一個(gè)分片單元,若為第一個(gè)分片單元,再對(duì)FU頭字節(jié)(載荷的第二個(gè)字節(jié))的后5個(gè)比特判斷NALU類型.只有包含第一個(gè)分片單元且FU頭字節(jié)中類型為5的RTP包才被判斷為IDR幀類型.

3.3 視頻流分發(fā)算法

如圖3所示,管道中每一個(gè)clientsink元件創(chuàng)建時(shí), streamdispatcher元件也會(huì)創(chuàng)建一個(gè)請(qǐng)求型source襯墊與該clientsink元件鏈接,承載實(shí)時(shí)視頻流的RTP包經(jīng)該source襯墊傳遞到與其連接的clientsink元件.創(chuàng)建請(qǐng)求型source襯墊的過(guò)程如算法1所示.

當(dāng)承載實(shí)時(shí)視頻流的RTP包從streamdispatcher元件的sink襯墊流入時(shí),streamdispatcher元件將流入的RTP包分發(fā)到使用算法1創(chuàng)建的source襯墊中,同時(shí)緩存當(dāng)前幀的IDR幀組數(shù)據(jù).這個(gè)過(guò)程使用算法2描述.算法2在streamdispatcher元件每接收到一個(gè)RTP數(shù)據(jù)包時(shí)都會(huì)被調(diào)用一次.

算法1中padContext為srcPad的上下文對(duì)象,包含兩個(gè)成員變量:sessionid和initialized.sessionid為整型,用于存放所創(chuàng)建襯墊對(duì)應(yīng)的 RTSP會(huì)話 ID. initialized為布爾型,表示該襯墊是否已經(jīng)接收到了初始IDR幀,初始值為FALSE.算法1的第6行表示srcPad設(shè)置上下文對(duì)象.

streamdispatcher元件使用列表變量srcPadList存放所有被請(qǐng)求創(chuàng)建的source襯墊,并用index變量記錄索引.算法1的第7行表示新創(chuàng)建的srcPad被加入到srcPadList列表中.

算法2中,idrGroupList是streamdispatcher元件用于緩存當(dāng)前IDR幀組的列表變量,在streamdispatcher元件初始化時(shí)創(chuàng)建且設(shè)初始值為空.rtpPkg是來(lái)自sink襯墊由IPC發(fā)送的RTP數(shù)據(jù)包,被parseFrameType函數(shù)用來(lái)判斷載荷中NALU類型是否為IDR幀類型 (判斷方法參考3.2節(jié),本文中只考慮單一NAL單元模式和分片封包模式).

算法2的第1至14行描述了向每個(gè)已創(chuàng)建source襯墊(包含在srcPadList中)推送數(shù)據(jù)的過(guò)程.算法2先根據(jù)每個(gè)source襯墊的上下文信息了解該襯墊是否已經(jīng)接收過(guò)初始IDR幀:如果該襯墊還未接收過(guò)初始幀:在緩存當(dāng)前IDR幀組的idrGroupList不為空且當(dāng)前NALU類型不為 IDR幀類型的條件下,先推送idrGroupList,再推送rtpPkg到該襯墊,并將上下文中的初始幀接收標(biāo)示置為TRUE;如果該襯墊已經(jīng)接收過(guò)初始IDR幀:只需要將當(dāng)前rtpPkg數(shù)據(jù)推送至該襯墊即可.

向source襯墊推送數(shù)據(jù)后,需要判斷當(dāng)前rtpPkg是否需要加入到idrGroupList中,算法2的第15至25行描述了這一個(gè)過(guò)程.如果當(dāng)前rtpPkg的NALU類型為IDR幀類型則表示idrGroupList已緩存的IDR幀組不再成為當(dāng)前IDR幀組,這時(shí)算法2清空idrGroupList后添加當(dāng)前rtpPkg到idrGroupList中.

算法2利用緩存的當(dāng)前IDR幀組保證了發(fā)送到各source襯墊的初始幀為IDR幀.

4 實(shí)驗(yàn)結(jié)果

應(yīng)用第2節(jié)介紹的架構(gòu),基于GStreamer 1.6版本開(kāi)發(fā)了一個(gè)簡(jiǎn)單的流媒體服務(wù)器,僅實(shí)現(xiàn)實(shí)時(shí)瀏覽IPC的功能.其中clientproxy元件和streamdispatcher元件都實(shí)現(xiàn)為獨(dú)立插件,ipcsrc元件和clientsink元件實(shí)現(xiàn)在一個(gè)插件當(dāng)中.基于GStreamer 1.6版本自帶的rtspsrc,decodebin,autovideosink等插件開(kāi)發(fā)了流媒體服務(wù)器的實(shí)時(shí)瀏覽客戶端,可用于實(shí)時(shí)瀏覽IPC監(jiān)控的視頻流.

服務(wù)器與IPC之間,客戶端與服務(wù)器之間都通過(guò)RTSP協(xié)議建立媒體會(huì)話并且使用RTP協(xié)議進(jìn)行視頻流傳輸.實(shí)驗(yàn)使用一個(gè)IPC作為視頻監(jiān)控前端,客戶端建立多個(gè)RTSP會(huì)話來(lái)測(cè)試streamdispatcher插件的分發(fā)效率.IPC視頻流為ES流,使用H.264編碼,分辨率為704×400,幀率為25fps,平均每3秒發(fā)送一個(gè)IDR幀.

實(shí)驗(yàn)所使用服務(wù)器為PC機(jī),操作系統(tǒng)為windows 7,CPU為英特爾酷睿雙核處理器(2.5GHZ),內(nèi)存為4GB.實(shí)驗(yàn)中針對(duì)不同的RTSP會(huì)話數(shù)目重點(diǎn)考察了streamdispatcher插件分發(fā)一個(gè)RTP包(執(zhí)行一次算法2)的時(shí)間,并和不使用streamdispatcher插件直接分發(fā)RTP包的時(shí)間做了比較.實(shí)驗(yàn)結(jié)果如圖5所示.

圖5 RTP包分發(fā)消耗時(shí)間及比較

圖5 中的消耗時(shí)間是分發(fā)一個(gè)RTP包到所有clientsink插件所消耗的時(shí)間(采集頭1000個(gè)RTP包的分發(fā)時(shí)間作為樣本,計(jì)算出平均時(shí)間).每個(gè)clientsink插件對(duì)應(yīng)一個(gè)RTSP會(huì)話,隨著會(huì)話數(shù)目的增加,分發(fā)時(shí)間也隨之增加.分發(fā)時(shí)間隨會(huì)話連接數(shù)目線性增加,這與算法2的邏輯擬合.

圖5對(duì)使用streamdispatcher插件分發(fā)和不使用streamdispatcher插件直接分發(fā)所消耗的時(shí)間進(jìn)行了比較.可以看到兩者在消耗時(shí)間上基本無(wú)差別,這是因?yàn)閟treamdispatcher插件只在直接分發(fā)流程上增加了一些條件判別,所增加的開(kāi)銷極小.

我們的實(shí)驗(yàn)?zāi)繕?biāo)設(shè)置為300路實(shí)時(shí)視頻流并發(fā)輸出能力.在會(huì)話連接數(shù)目達(dá)到300時(shí),一個(gè)RTP包發(fā)送到所有clientsink插件的消耗時(shí)間為542206納秒.使用抓包工具得知IPC平均一秒內(nèi)大約發(fā)送60個(gè)RTP包,因而streamdispatcher插件的轉(zhuǎn)發(fā)能力完全能夠滿足實(shí)驗(yàn)?zāi)繕?biāo).

Streamdispatcher插件保證了發(fā)送到客戶端的初始幀為IDR幀,這也使得視頻監(jiān)控的效果得到了提升,圖 6展示了使用 streamdispatcher插件和未使用streamdispatcher插件的視頻監(jiān)控效果.

圖6 streamdispatcher插件使用與否的效果比對(duì)

圖6 中,未使用streamdispatcher插件的流媒體服務(wù)器發(fā)送到客戶端的初始畫面出現(xiàn)花屏現(xiàn)象,而使用streamdispatcher插件的流媒體服務(wù)器保證了客戶端初始畫面的完整性,提升了視頻監(jiān)控效果.

5 結(jié)語(yǔ)

本文基于GStreamer框架,針對(duì)H.264編碼規(guī)范,設(shè)計(jì)并實(shí)現(xiàn)了一種實(shí)時(shí)視頻流分發(fā)插件:使用隨機(jī)創(chuàng)建的請(qǐng)求型source襯墊完成數(shù)據(jù)的分發(fā),并通過(guò)緩存當(dāng)前IDR幀組的方法保證了發(fā)送的初始幀為IDR幀,解決了視頻監(jiān)控初始畫面花屏的問(wèn)題.本文所描述的插件可應(yīng)用于流媒體服務(wù)器當(dāng)中,實(shí)驗(yàn)證明這種保證了初始數(shù)據(jù)完整性的實(shí)時(shí)視頻流分發(fā)插件在高效轉(zhuǎn)發(fā)的同時(shí),也大大提升了實(shí)時(shí)視頻監(jiān)控效果.

雖然本文討論的插件針對(duì)H.264編碼規(guī)范,但這種在視頻分發(fā)端緩存當(dāng)前IDR幀組以保證初始視頻數(shù)據(jù)完整性的思路仍可擴(kuò)展到兼容多種編碼格式的流媒體服務(wù)器設(shè)計(jì)當(dāng)中.

1 Wiegand T,Sullivan G J,Bjontegaard G,Luthra A.Overview of the H.264/AVC video coding standard.IEEE Trans.on Circuits&SystemsforVideoTechnology,2003,13(7):560–576.

2楊戈,廖建新,朱曉民,樊秀梅.流媒體分發(fā)系統(tǒng)關(guān)鍵技術(shù)綜述.電子學(xué)報(bào),2009,37(1):137–145.

3 Taymans W,Baker S,Wingo A,Bultje RS,Kost S.GStreamer Application Development Manual(1.6.0).2013.https://gstreamer. freedesktop.org/documentation/.

4劉興民,趙連軍.基于GStreamer的遠(yuǎn)程視頻監(jiān)控系統(tǒng)的關(guān)鍵技術(shù)研究.計(jì)算機(jī)應(yīng)用與軟件,2011,28(5):243–246.

5 Boulton RJ,Walthinsen E,Baker S,Johnson L,Bultje RS, Kost S,Müller TP,Taymans W.GStreamer Plugin Writer’s Guide(1.6.0). 2013. https://gstreamer.freedesktop.org/ documentation/.

6計(jì)文平,郭寶龍,丁貴廣.新一代視頻編碼國(guó)際標(biāo)準(zhǔn)的研究.計(jì)算機(jī)應(yīng)用與軟件,2004,21(2):60–62.

7 Schulzrinne H,Rao A,Lanphier R.Real Time Streaming Protocol(RTSP).RFC 2326,Internet Engineering Task Force, 1998,4.

8 Schulzrinne H,Casner S,Frederick R,Jacobson V.RTP:A Transport Protocol for Real-Time Applications.RFC 3550, Internet Engineering Task Force,2003,7.

Real Time Video Stream Dispatch Plugin for Ensuring the Integrity of Initial Data

ZHANG Kai

(Suzhou Keda Technology Co.Ltd.,Shanghai R&D Center,Shanghai 201103,China)

In the real time video surveillance network system,if the initial video data

by the monitoring client is not complete,the screen will show blurred screen.For H.264 coding standard,this paper designs and implements real time video stream dispatch plugin based on the open source multimedia GStreamer framework.The plugin uses a randomly requested source pad to dispatch video data.It also caches current IDR frames group to ensure the integrity of initial IDR frame to be sent.The plugin can be used in streaming media server to solve the problem of the blurred screen of initial screen effect in video surveillance.Experiment shows that the streaming media server with this plugin can effectively distribute the real time video data and ensure the integrity of the initial playback screen,which has a significant effect on improving the real-time monitoring effect.

video surveillance;streaming media server;GStreamer framework;H.264 standard;IDR frame;RTPprotocol

2016-08-28;收到修改稿時(shí)間:2016-09-27

10.15888/j.cnki.csa.005747