基于Live555的實時視頻傳輸系統(tǒng)設(shè)計及其方法

魏崇毓，田文鵬

（青島科技大學(xué) 山東 青島 266061）

基于Live555的實時視頻傳輸系統(tǒng)設(shè)計及其方法

魏崇毓，田文鵬

（青島科技大學(xué) 山東 青島 266061）

目前實時視頻傳輸技術(shù)已經(jīng)得到廣泛的應(yīng)用。就基于Live555的視頻傳輸系統(tǒng)存在的時延大、數(shù)據(jù)傳輸不穩(wěn)定等問題進(jìn)行研究，為達(dá)到降低實時視頻傳輸系統(tǒng)的時延和提高數(shù)據(jù)傳輸?shù)姆€(wěn)定性的目的，對其進(jìn)行優(yōu)化設(shè)計，采用了一種實時化處理和自適應(yīng)重傳機(jī)制的方法，通過系統(tǒng)實際應(yīng)用試驗，得出系統(tǒng)延時降為863ms，視頻傳輸流暢穩(wěn)定的結(jié)果。

Live555；實時視頻傳輸；實時化處理；自適應(yīng)重傳機(jī)制

隨著無線通信技術(shù)的發(fā)展以及以智能手機(jī)為代表的便攜式移動終端的普及，為構(gòu)建面向移動環(huán)境的實時視頻傳輸系統(tǒng)提供了條件。在網(wǎng)絡(luò)視頻聊天、視頻會議以及醫(yī)療示教等對實時性要求較強(qiáng)的領(lǐng)域，視頻播放的延時成為衡量系統(tǒng)性能的關(guān)鍵指標(biāo)，目前以智能手機(jī)作為采集設(shè)備的視頻傳輸系統(tǒng)往往會出現(xiàn)比較大的延時，視頻傳輸?shù)馁|(zhì)量也不能得到有效保障[1]。文中以live555開源項目為基礎(chǔ)，通過對其進(jìn)行優(yōu)化設(shè)計，實現(xiàn)了低延時高質(zhì)量的實時視頻傳輸系統(tǒng)。

1 視頻傳輸系統(tǒng)相關(guān)技術(shù)

1.1 H.264

H.264是一種面向塊的高性能的視頻編解碼標(biāo)準(zhǔn)，H.264具有低碼率、高質(zhì)量圖像、容錯能力強(qiáng)以及網(wǎng)絡(luò)適應(yīng)性強(qiáng)等優(yōu)點。與MPEG-4相比H.264可以提高50%的壓縮比率，在傳輸上，H.264可以在較低碼率下傳送高質(zhì)量的視頻流，更適合與無線網(wǎng)絡(luò)的視頻傳輸[2-3]。

1.2 Live555

live555是一種跨平臺、開源的流媒體解決方案，它不僅實現(xiàn)了對如RTSP、RTP/RTCP等標(biāo)準(zhǔn)流媒體傳輸協(xié)議的支持[4]，而且也支持如MPEG、H.264、JPEG等多種音視頻編碼格式的流媒體數(shù)據(jù)的流化、接收和處理。同時live555擁有良好的結(jié)構(gòu)化設(shè)計，使其易于擴(kuò)展對其他流媒體格式的支持[5-6]。目前，live555已經(jīng)被用于如VLC、MPlayer等眾多播放器的流媒體播放功能中。

2 實時化處理方法

從采集端傳到服務(wù)器端的數(shù)據(jù)是進(jìn)行H264編碼后的視頻數(shù)據(jù)流，H264視頻數(shù)據(jù)流必須要從I幀（關(guān)鍵幀）開始才能播放，I幀是一個全幀畫面壓縮而成的編碼幀，播放時解碼還需要SPS（序列參數(shù)集）和PPS（圖像參數(shù)集）才能重構(gòu)完整圖像，所以SPS和PPS需要在視頻開頭同I幀一起傳輸。H264視頻數(shù)據(jù)的格式開頭為SPS和PPS，接著是編碼器的參數(shù)信息，然后才是I幀[7]。要實現(xiàn)實時的視頻傳輸，需要將H264視頻數(shù)據(jù)中的SPS、PPS和I幀截取下來保存到緩沖區(qū)中，然后實時刷新緩沖區(qū)，以保證數(shù)據(jù)的實時性，如果沒有播放請求，當(dāng)緩沖區(qū)內(nèi)緩存幀數(shù)達(dá)到一定數(shù)目時就將緩沖區(qū)清空接收新數(shù)據(jù)，當(dāng)有播放請求時，就將最新的數(shù)據(jù)傳給服務(wù)器，以此確保服務(wù)器傳給播放端的數(shù)據(jù)是最新的，實現(xiàn)視頻數(shù)據(jù)的實時傳輸。

緩沖區(qū)的刷新是根據(jù)其保存的I幀的個數(shù)Iframe_num來判定的，當(dāng)緩沖區(qū)內(nèi)I幀數(shù)達(dá)到設(shè)定的Iframe_num時就將緩沖區(qū)刷新清空并接收新的數(shù)據(jù)，對H264數(shù)據(jù)格式進(jìn)行分析得出I幀的起始標(biāo)志為00 00 01 65[8]，可以根據(jù)其來計算I幀的個數(shù)。Iframe_num的設(shè)定對時延以及數(shù)據(jù)傳輸?shù)姆€(wěn)定性有很大的影響，例如假定Iframe_num=N，也就是說緩沖區(qū)內(nèi)有N個I幀，當(dāng)有播放請求時是從第一個I幀開始播放的，但是實際上最新的數(shù)據(jù)是第N個I幀，這樣就會產(chǎn)生N幀的延遲。所以如果Iframe_num設(shè)置過大，數(shù)據(jù)傳輸相對穩(wěn)定，但是時延會變大，時延過大就滿足不了視頻傳輸實時性的要求。如果Iframe_num設(shè)置過小，時延會小，但是視頻的會不穩(wěn)定，會導(dǎo)致數(shù)據(jù)來不及及時送入服務(wù)器，造成播放的中斷。為保證實時視頻傳輸?shù)膶崟r性及穩(wěn)定性，我們可以進(jìn)行這樣的設(shè)計：當(dāng)沒有播放請求的時候，將Iframe_num設(shè)為1，這樣有播放端連接進(jìn)行實時播放時產(chǎn)生的延時是最小的，當(dāng)已經(jīng)與播放端連接進(jìn)行實時視頻傳輸后，緩沖區(qū)中I幀的個數(shù)就不會對時延產(chǎn)生太大影響了，這時為保證數(shù)據(jù)傳輸?shù)姆€(wěn)定性，同時考慮接收緩沖區(qū)中數(shù)據(jù)到達(dá)的速率與數(shù)據(jù)讀取的速率，將Iframe_num重置為3較為合適。

整個模塊的具體實現(xiàn)過程如下：

1）將采集端傳過來的數(shù)據(jù)中頭部的SPS、PPS以及I幀截取下來保存到緩沖區(qū)中。

2）在有播放鏈接之前將緩沖區(qū)刷新參數(shù)Iframe_num設(shè)為1。

3）監(jiān)聽是否已經(jīng)與播放端建立連接，若沒有，刷新緩沖區(qū)繼續(xù)監(jiān)聽，若已經(jīng)連接，就將緩沖區(qū)參數(shù)Iframe_num重置為3。

4）監(jiān)聽服務(wù)器是否與播放端斷開連接。若沒有，保持Iframe_num為3；若已經(jīng)斷開，則將Iframe_num重新設(shè)為1，以確保下一次實時視頻傳輸?shù)臅r延最小。

流程圖如圖1所示。

圖1 實時處理邏輯流程圖

3 自適應(yīng)重傳機(jī)制

當(dāng)采集端使用智能手機(jī)作為采集設(shè)備時，既要進(jìn)行視頻采集又要進(jìn)行編碼，這對智能手機(jī)的處理能力要求比較高，當(dāng)手機(jī)的內(nèi)存占用率過高就會導(dǎo)致手機(jī)的數(shù)據(jù)處理能力不夠，再加上網(wǎng)絡(luò)的原因，視頻數(shù)據(jù)不能及時的傳送給服務(wù)器端，服務(wù)器端接收不到數(shù)據(jù)就會造成播放端在進(jìn)行實時視頻播放時突然中斷，為解決這個問題，保證視頻傳輸?shù)姆€(wěn)定性，本節(jié)提出了一種自適應(yīng)重傳機(jī)制。

3.1 自適應(yīng)重傳機(jī)制框架

自適應(yīng)重傳機(jī)制框架如圖2所示。

圖2 自適應(yīng)重傳機(jī)制框架

自適應(yīng)重傳機(jī)制框架涉及整個視頻傳輸系統(tǒng)的采集端和服務(wù)器端，主要模塊包括重傳模塊和自適應(yīng)調(diào)節(jié)模塊。要使live555支持實時的視頻傳輸，需要自己新建一個可以從內(nèi)存中讀取數(shù)據(jù)的數(shù)據(jù)源來代替原有的從文件中讀取數(shù)據(jù)的數(shù)據(jù)源，新建的數(shù)據(jù)源從服務(wù)器接收緩沖區(qū)中讀取數(shù)據(jù)，如果某一時間段內(nèi)，由于采集端設(shè)備的數(shù)據(jù)處理能力下降或者是網(wǎng)絡(luò)出現(xiàn)擁塞，會導(dǎo)致數(shù)據(jù)不能及時的傳送到服務(wù)器，數(shù)據(jù)源讀取不到新的數(shù)據(jù)，就會出現(xiàn)播放端視頻播放中斷的現(xiàn)象，傳統(tǒng)的重傳方法并不適用于對實時性要求高的視頻傳輸系統(tǒng)[9-10]，為解決這個問題，文中提出了一種自適應(yīng)重傳機(jī)制，其流程可簡要描述如下：數(shù)據(jù)源在數(shù)據(jù)的時候先判斷是否有新的數(shù)據(jù)，如果有，則讀取新的數(shù)據(jù)，如果沒有，進(jìn)入重傳模塊，將已經(jīng)讀取到的數(shù)據(jù)進(jìn)行重傳，并記錄重傳次數(shù)，自適應(yīng)調(diào)節(jié)模塊根據(jù)重傳次數(shù)來計算采集端視頻碼流發(fā)送速率調(diào)整幅度，然后反饋到采集端，采集端根據(jù)反饋信息調(diào)整視頻碼流發(fā)送速率，來保證視頻數(shù)據(jù)能及時到達(dá)服務(wù)器端，保持?jǐn)?shù)據(jù)的連續(xù)性。接下來分別詳細(xì)說明重傳模塊和自適應(yīng)調(diào)節(jié)模塊。

3.2 重傳模塊

首先判斷服務(wù)器接收緩沖區(qū)是否接收到新數(shù)據(jù)，如果有，數(shù)據(jù)源正常讀取數(shù)據(jù)進(jìn)行實時傳送，如果沒有，就將數(shù)據(jù)源中用于讀取數(shù)據(jù)的指針往回偏移重傳已經(jīng)保存的數(shù)據(jù)，以保持?jǐn)?shù)據(jù)的連續(xù)性，防止視頻播放中斷。如果流媒體服務(wù)器端的緩沖區(qū)一直沒有接收到新視頻數(shù)據(jù)，重傳模塊循環(huán)執(zhí)行偏移操作并記錄offset_num（重傳次數(shù)），作為自適應(yīng)調(diào)節(jié)模塊的輸入?yún)?shù)。一般情況下，重傳一定次數(shù)后，就會收到新數(shù)據(jù)，對視頻的播放不會產(chǎn)生太大影響，但當(dāng)重傳超過一定次數(shù)之后，說明采集端長時間沒有數(shù)據(jù)傳過來，這時就要采取一定的措施，在自適應(yīng)調(diào)節(jié)模塊提出解決措施。

3.3 自適應(yīng)調(diào)節(jié)模塊

自適應(yīng)調(diào)節(jié)模塊是以重傳模塊的重傳次數(shù)offset_num為輸入?yún)?shù)，通過算法確定采集端視頻碼流發(fā)送速率的調(diào)節(jié)動作，文中將調(diào)節(jié)動作定義為視頻碼流發(fā)送速率調(diào)節(jié)幅度。實現(xiàn)時根據(jù)實際采用的視頻編碼格式，選用適當(dāng)?shù)木幋a選項及相關(guān)參數(shù)，已達(dá)到需要的視頻碼流發(fā)送速率調(diào)節(jié)幅度。這樣，對于自適應(yīng)調(diào)節(jié)模塊的調(diào)節(jié)動作就可以看作采集端視頻碼流發(fā)送速率的調(diào)節(jié)幅度與重傳次數(shù)offset_num的一種對應(yīng)關(guān)系。

根據(jù)重傳次數(shù)offset_num，可以確定數(shù)據(jù)從采集端到服務(wù)器端的傳輸狀況，從實際應(yīng)用考慮，進(jìn)行自適應(yīng)調(diào)節(jié)要有實時性的要求，在準(zhǔn)確性與實時性的權(quán)衡下，文中采用粗粒度的判別方式，以期能及時反映出數(shù)據(jù)的傳輸狀況，及時做出調(diào)整。因此為重傳次數(shù)offset_num設(shè)定兩個閥值TL和TH，數(shù)據(jù)傳輸狀況可根據(jù)offset_num劃分為3個區(qū)域，如圖3所示。區(qū)域state1表示offset_num較小，數(shù)據(jù)重傳對視頻的播放影響不大，這種情況下不需要對采集端發(fā)送速率進(jìn)行調(diào)整；區(qū)域state2表示數(shù)據(jù)重傳次數(shù)offset_num對視頻的播放產(chǎn)生影響，出現(xiàn)部分花屏現(xiàn)象，這時就需要對采集端發(fā)送速率進(jìn)行調(diào)整；區(qū)域state3表示數(shù)據(jù)重傳次數(shù)超過最高限值，說明較長的時間內(nèi)沒有數(shù)據(jù)發(fā)送過來，采集端與服務(wù)端的連接出現(xiàn)問題，這時采取斷開重連的措施，這樣就實現(xiàn)對數(shù)據(jù)傳輸狀況的一個粗粒度的判別和劃分。

圖3 數(shù)據(jù)傳輸狀態(tài)劃分

在文中的設(shè)計方案中，采集端視頻碼流發(fā)送速率調(diào)節(jié)幅度ΔC和重傳次數(shù)offset_num的關(guān)系用式（1）的算法表示：

采集端視頻碼流發(fā)送速率的調(diào)節(jié)幅度ΔC是根據(jù)前面所敘述的由offset_num劃分的3種數(shù)據(jù)傳輸狀況來計算的，計算基于調(diào)節(jié)范圍Range（根據(jù)實際需要預(yù)先設(shè)定），根據(jù)實際需要設(shè)定一個權(quán)值a來實現(xiàn)不同的調(diào)節(jié)幅度，以滿足實際傳輸情況的需要。

如果ΔC過大會引起采集端發(fā)送數(shù)據(jù)瞬時巨大波動，為了避免出現(xiàn)這種頻繁的波動，我們要對ΔC進(jìn)行平滑處理，用平滑處理后的ΔC來實現(xiàn)對采集端數(shù)據(jù)發(fā)送速率的調(diào)節(jié)。平滑計算過程為式（2）：

其中，ΔC′是本次平滑處理后的調(diào)節(jié)幅度，ΔC（n-1）是上一次平滑處理后的調(diào)節(jié)幅度，ΔC（n）是本次計算得到的調(diào)節(jié)幅度。當(dāng)t增加時，本次計算的調(diào)節(jié)幅度ΔC（n）對結(jié)果影響增大；當(dāng)t減小時，上一次平滑處理后的調(diào)節(jié)幅度ΔC（n-1）對結(jié)果影響增大。

自適應(yīng)調(diào)節(jié)模塊的執(zhí)行過程如下：

1）根據(jù)重傳模塊記錄的重傳次數(shù)offset_num來判別當(dāng)前數(shù)據(jù)傳輸?shù)臓顩r。

2）根據(jù)數(shù)據(jù)傳輸狀況計算ΔC

①若重傳次數(shù)小于閥值TL（預(yù)先設(shè)定），則可以認(rèn)為數(shù)據(jù)的重傳對播放的影響不大，不需要的對采集端視頻碼流的發(fā)送速率進(jìn)行調(diào)節(jié)，即ΔC=0。

②若重傳次數(shù)大于閥值TL且小于TH，這時數(shù)據(jù)的重傳就會對視頻播放造成一定影響，出現(xiàn)花屏現(xiàn)象，需要對采集端視頻碼流的發(fā)送速率進(jìn)行調(diào)節(jié)，調(diào)節(jié)幅度ΔC=a×Range。

③若重傳次數(shù)大于閥值TH，這時數(shù)據(jù)重傳就會對視頻播放造成較大影響，導(dǎo)致出現(xiàn)卡屏現(xiàn)象，這時就可認(rèn)為數(shù)據(jù)的傳輸出現(xiàn)問題，中斷本次連接。

3）將計算出的ΔC進(jìn)行平滑處理。

4）將平滑處理后的調(diào)節(jié)幅度ΔC′反饋給采集端。

圖4 自適應(yīng)模塊流程圖

文中提出的自適應(yīng)調(diào)節(jié)策略是以網(wǎng)絡(luò)帶寬足夠為前提的，該方法以重傳模塊的重傳次數(shù)為輸入?yún)?shù)，上面描述的只是一次的調(diào)節(jié)動作，實際調(diào)節(jié)時，需要多次調(diào)節(jié)才能達(dá)到理想情況。本方法中使用的劃分?jǐn)?shù)據(jù)傳輸狀況的閥值TL和TH、調(diào)節(jié)范圍Range等參數(shù)都可以根據(jù)實際環(huán)境的需要來自行設(shè)定，通過合理參數(shù)設(shè)定使自適應(yīng)調(diào)節(jié)策略達(dá)到滿意的效果。

4 Live555流媒體服務(wù)器設(shè)計

實時視頻傳輸系統(tǒng)主要有采集端、服務(wù)器端和播放端3部分組成。采集端使用智能手機(jī)設(shè)備進(jìn)行視頻的采集，同時采集端還要完成對視頻數(shù)據(jù)的H.264編碼，然后將視頻數(shù)據(jù)發(fā)送給服務(wù)器。服務(wù)器端要將接收到的數(shù)據(jù)進(jìn)行實時的流化處理，依據(jù)RTP協(xié)議規(guī)則將數(shù)據(jù)打包成標(biāo)準(zhǔn)的RTP包，然后使用RTSP協(xié)議與播放端進(jìn)行交互，將RTP包發(fā)送到播放端。播放端使用VLC播放器接收、解碼和播放視頻[11-13]。文中主要是針對服務(wù)器端流媒體服務(wù)器的設(shè)計。

Live555流媒體服務(wù)器主要負(fù)責(zé)將從采集端傳過來的視頻數(shù)據(jù)進(jìn)行實時的流化處理，依據(jù)RTP協(xié)議將數(shù)據(jù)打包成標(biāo)準(zhǔn)的RTP包，然后使用RTSP協(xié)議與播放端進(jìn)行交互，將RTP包發(fā)送到播放端[14-15]。Live555開源項目默認(rèn)的數(shù)據(jù)傳輸邏輯是基于視頻文件點播的，要想實現(xiàn)實時的視頻傳輸，一方面要在接收緩沖區(qū)中對數(shù)據(jù)進(jìn)行實時化處理；另一方面要修改Live555中的數(shù)據(jù)傳輸結(jié)構(gòu)以及抽象數(shù)據(jù)源與接口，新建一個數(shù)據(jù)源Source，實現(xiàn)從緩沖區(qū)內(nèi)存中讀取數(shù)據(jù)來代替原來從視頻文件中讀取數(shù)據(jù)的數(shù)據(jù)源。

采集端將采集的視頻數(shù)據(jù)進(jìn)行編碼之后，以UDP方式將數(shù)據(jù)傳輸?shù)搅髅襟w服務(wù)器上，服務(wù)器上視頻接口負(fù)責(zé)從特定的端口上接收UDP數(shù)據(jù)包，并將其保存到數(shù)據(jù)緩沖區(qū)中。然后通過實時化處理邏輯對數(shù)據(jù)進(jìn)行實時化處理。重傳模塊負(fù)責(zé)判斷緩沖區(qū)中是否接收到新的數(shù)據(jù)，確定是否需要進(jìn)行數(shù)據(jù)重傳以保持?jǐn)?shù)據(jù)的連續(xù)性，然后再配合自適應(yīng)調(diào)節(jié)模塊來完成對采集端數(shù)據(jù)發(fā)送速率的動態(tài)調(diào)節(jié)。接著，創(chuàng)建一個對應(yīng)于實時數(shù)據(jù)的數(shù)據(jù)源Source，服務(wù)器中所有讀取實時數(shù)據(jù)的操作都是通過這個數(shù)據(jù)源進(jìn)行的。RTSP交互模塊負(fù)責(zé)與播放端進(jìn)行交互，當(dāng)接收的播放端發(fā)送的DESCRIBE請求時，就會獲取到對應(yīng)的流媒體信息的SDP（Session Description Protocol）描述信息發(fā)送給播放端，當(dāng)收到播放端發(fā)送的SETUP請求時，會向會話管理模塊請求建立一個新的會話Session和新的數(shù)據(jù)消費對象Sink，服務(wù)器所有發(fā)送數(shù)據(jù)的操作都是通過這個Sink進(jìn)行的，一個Session表示一個服務(wù)器與播放端的連接，同時也就建立一個Source與Sink之間的連接。最后，當(dāng)服務(wù)器收到播放端發(fā)送的PLAY請求時，數(shù)據(jù)就會通過已建立的連接，經(jīng)過RTP編碼模塊對數(shù)據(jù)進(jìn)行RTP打包發(fā)送到播放端。

流媒體服務(wù)器架構(gòu)設(shè)計如圖5所示。

圖5 流媒體服務(wù)器架構(gòu)設(shè)計圖

流媒體服務(wù)器設(shè)計的重點就是實現(xiàn)實時視頻流的接收與發(fā)送，同時還要保持視頻傳輸?shù)姆€(wěn)定。本文在流媒體服務(wù)器的設(shè)計時在接收緩沖區(qū)中加入了實時處理邏輯，有效的減小了實時視頻傳輸?shù)臅r延，同時在緩沖區(qū)與數(shù)據(jù)源之間加入重傳模塊，并通過其與自適應(yīng)調(diào)節(jié)模塊的協(xié)調(diào)配合，可以有效的保證視頻數(shù)據(jù)傳輸?shù)姆€(wěn)定性，防止實時視頻播放過程中的突然中斷。

5 系統(tǒng)測試結(jié)果

測試結(jié)果表明，對流媒體服務(wù)器進(jìn)行優(yōu)化設(shè)計之后，時延明顯減小，可以滿足視頻傳輸系統(tǒng)對實時性的要求，同時視頻質(zhì)量也有很大改善，如表1所示。優(yōu)化之前視頻會經(jīng)常出現(xiàn)大塊拉長的現(xiàn)象，優(yōu)化之后偶爾也會出現(xiàn)拉長現(xiàn)象但是很快就會恢復(fù)，視頻流暢性更好。優(yōu)化前后視頻畫面圖像如圖6、7所示。

表1 流媒體服務(wù)器優(yōu)化前后對比

圖6 優(yōu)化之前視頻畫面

圖7 優(yōu)化之后視頻畫面

6 結(jié)束語

文中對Live555流媒體服務(wù)器進(jìn)行優(yōu)化設(shè)計，提出了一種實時化處理邏輯，實現(xiàn)了流媒體服務(wù)器的實時視頻傳輸，減小了實時視頻傳輸系統(tǒng)的時延。另外還提出了一種自適應(yīng)重傳機(jī)制，當(dāng)采集端數(shù)據(jù)不能及時傳到服務(wù)器時，自適應(yīng)重傳機(jī)制能夠保持?jǐn)?shù)據(jù)傳輸?shù)倪B續(xù)性，防止因數(shù)據(jù)傳輸?shù)牟环€(wěn)定造成播放端視頻播放的中斷，同時也能提高了視頻的質(zhì)量。視頻數(shù)據(jù)傳輸?shù)馁|(zhì)量與網(wǎng)絡(luò)的狀況也有很大關(guān)系，可以在現(xiàn)有的基礎(chǔ)上對自適應(yīng)重傳機(jī)制進(jìn)行進(jìn)一步研究，使其同時能根據(jù)當(dāng)前網(wǎng)絡(luò)的狀況進(jìn)行調(diào)節(jié)，更有效的提高視頻傳輸?shù)馁|(zhì)量。

[2]H Krichene.Performance/complexity analysis of a H264 video encoder[J].International Review on Computers&Software，2007（4）:401-414.

[3]王彤.基于FFmpeg的H.264解碼器實現(xiàn)[D].大連：大連理工大學(xué)，2011.

[4]高建水.基于RTSP協(xié)議的視頻點播系統(tǒng)設(shè)計[J].電子器件，2006，29（4）:1143-1146.

[5]Live555 Media Server. [EB/OL].http://www.live555.com/ mediaServer/.

[6]劉暢欞，包杰，王寧國.基于Live555的網(wǎng)絡(luò)視頻監(jiān)控技術(shù)與實現(xiàn)[J].現(xiàn)代電子科技，2012，12（12）：38-42.

[7]孫泉.支持H.264的實施流媒體服務(wù)器的設(shè)計與實現(xiàn)[D].北京：北京郵電大學(xué)，2010.

[8]黃帥.流媒體服務(wù)器在視頻數(shù)據(jù)傳輸中的應(yīng)用[D].青島：青島科技大學(xué)，2014.

[9]Khan S Q.Experiences with blending HTTP，RTSP，and IMS IP Multimedia Systems（IMS）infrastructure and services [J].Communications Magazine，IEEE，2007（4）:122-128.

[10]呂少君，周淵平.基于Live555的實時流媒體傳輸系統(tǒng)[J].計算機(jī)應(yīng)用與軟件，2015，24（1）:56-59.

[11]劉大紅.基于RTSP流媒體服務(wù)器的設(shè)計與實現(xiàn)[D].西安：西安電子科技大學(xué)，2014.

[12]章民融.基于RTSP的流媒體視頻服務(wù)器的設(shè)計與實現(xiàn)[J].計算機(jī)應(yīng)用與軟件，2006（8）:93-95.

[13]李校林.RTP/RTCP，RTSP在無線視頻監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)[J].視頻應(yīng)用與工程，2011，35（19）:89-92.

[14]涂兵，肖洪祥.流媒體服務(wù)器中音視頻幀封裝研究[J].計算機(jī)應(yīng)用，2008（28）:51-55.

[15]Jong Min Lee，Proxy-based Multimedia Signaling Scheme Using RTSP for Seamless Service Mobility in Home Network [J].2008（5）:481-486.

Design of the real-time video transmission system based on Live555 and its methods

WEI Chong-yu，TIAN Wen-peng
（Qingdao University of Science&Technology，Qingdao 266061，China）

At present，real-time video transmission system has been widely used.Real-time video transmission system based on live555 has the problem of time delay and data transmission instability.Based on the study of these problems，to achieve the purpose of reducing the time delay of real-time video transmission system effectively and improving the stability of data transmission，a real-time processing method and an adaptive retransmission strategy are provided.The system test result shows that the time delay reduce to 863ms and video transmission smooth and stable.

Live555；real-time video transmission；real-time processing；adaptive retransmission strategy

TN919

A

1674－6236（2016）23-0089-04

2015-12-04稿件編號：201512039

魏崇毓（1957—），男，山東青島人，博士，教授。研究方向：無線通信。