基于Live555的實時視頻傳輸系統設計及其方法

魏崇毓，田文鵬

（青島科技大學 山東 青島 266061）

基于Live555的實時視頻傳輸系統設計及其方法

魏崇毓，田文鵬

（青島科技大學 山東 青島 266061）

目前實時視頻傳輸技術已經得到廣泛的應用。就基于Live555的視頻傳輸系統存在的時延大、數據傳輸不穩定等問題進行研究，為達到降低實時視頻傳輸系統的時延和提高數據傳輸的穩定性的目的，對其進行優化設計，采用了一種實時化處理和自適應重傳機制的方法，通過系統實際應用試驗，得出系統延時降為863ms，視頻傳輸流暢穩定的結果。

Live555；實時視頻傳輸；實時化處理；自適應重傳機制

隨著無線通信技術的發展以及以智能手機為代表的便攜式移動終端的普及，為構建面向移動環境的實時視頻傳輸系統提供了條件。在網絡視頻聊天、視頻會議以及醫療示教等對實時性要求較強的領域，視頻播放的延時成為衡量系統性能的關鍵指標，目前以智能手機作為采集設備的視頻傳輸系統往往會出現比較大的延時，視頻傳輸的質量也不能得到有效保障[1]。文中以live555開源項目為基礎，通過對其進行優化設計，實現了低延時高質量的實時視頻傳輸系統。

1 視頻傳輸系統相關技術

1.1 H.264

H.264是一種面向塊的高性能的視頻編解碼標準，H.264具有低碼率、高質量圖像、容錯能力強以及網絡適應性強等優點。與MPEG-4相比H.264可以提高50%的壓縮比率，在傳輸上，H.264可以在較低碼率下傳送高質量的視頻流，更適合與無線網絡的視頻傳輸[2-3]。

1.2 Live555

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

2 實時化處理方法

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

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

整個模塊的具體實現過程如下：

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

2）在有播放鏈接之前將緩沖區刷新參數Iframe_num設為1。

3）監聽是否已經與播放端建立連接，若沒有，刷新緩沖區繼續監聽，若已經連接，就將緩沖區參數Iframe_num重置為3。

4）監聽服務器是否與播放端斷開連接。若沒有，保持Iframe_num為3；若已經斷開，則將Iframe_num重新設為1，以確保下一次實時視頻傳輸的時延最小。

流程圖如圖1所示。

圖1 實時處理邏輯流程圖

3 自適應重傳機制

當采集端使用智能手機作為采集設備時，既要進行視頻采集又要進行編碼，這對智能手機的處理能力要求比較高，當手機的內存占用率過高就會導致手機的數據處理能力不夠，再加上網絡的原因，視頻數據不能及時的傳送給服務器端，服務器端接收不到數據就會造成播放端在進行實時視頻播放時突然中斷，為解決這個問題，保證視頻傳輸的穩定性，本節提出了一種自適應重傳機制。

3.1 自適應重傳機制框架

自適應重傳機制框架如圖2所示。

圖2 自適應重傳機制框架

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

3.2 重傳模塊

首先判斷服務器接收緩沖區是否接收到新數據，如果有，數據源正常讀取數據進行實時傳送，如果沒有，就將數據源中用于讀取數據的指針往回偏移重傳已經保存的數據，以保持數據的連續性，防止視頻播放中斷。如果流媒體服務器端的緩沖區一直沒有接收到新視頻數據，重傳模塊循環執行偏移操作并記錄offset_num（重傳次數），作為自適應調節模塊的輸入參數。一般情況下，重傳一定次數后，就會收到新數據，對視頻的播放不會產生太大影響，但當重傳超過一定次數之后，說明采集端長時間沒有數據傳過來，這時就要采取一定的措施，在自適應調節模塊提出解決措施。

3.3 自適應調節模塊

自適應調節模塊是以重傳模塊的重傳次數offset_num為輸入參數，通過算法確定采集端視頻碼流發送速率的調節動作，文中將調節動作定義為視頻碼流發送速率調節幅度。實現時根據實際采用的視頻編碼格式，選用適當的編碼選項及相關參數，已達到需要的視頻碼流發送速率調節幅度。這樣，對于自適應調節模塊的調節動作就可以看作采集端視頻碼流發送速率的調節幅度與重傳次數offset_num的一種對應關系。

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

圖3 數據傳輸狀態劃分

在文中的設計方案中，采集端視頻碼流發送速率調節幅度ΔC和重傳次數offset_num的關系用式（1）的算法表示：

采集端視頻碼流發送速率的調節幅度ΔC是根據前面所敘述的由offset_num劃分的3種數據傳輸狀況來計算的，計算基于調節范圍Range（根據實際需要預先設定），根據實際需要設定一個權值a來實現不同的調節幅度，以滿足實際傳輸情況的需要。

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

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

自適應調節模塊的執行過程如下：

1）根據重傳模塊記錄的重傳次數offset_num來判別當前數據傳輸的狀況。

2）根據數據傳輸狀況計算ΔC

①若重傳次數小于閥值TL（預先設定），則可以認為數據的重傳對播放的影響不大，不需要的對采集端視頻碼流的發送速率進行調節，即ΔC=0。

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

③若重傳次數大于閥值TH，這時數據重傳就會對視頻播放造成較大影響，導致出現卡屏現象，這時就可認為數據的傳輸出現問題，中斷本次連接。

3）將計算出的ΔC進行平滑處理。

4）將平滑處理后的調節幅度ΔC′反饋給采集端。

圖4 自適應模塊流程圖

文中提出的自適應調節策略是以網絡帶寬足夠為前提的，該方法以重傳模塊的重傳次數為輸入參數，上面描述的只是一次的調節動作，實際調節時，需要多次調節才能達到理想情況。本方法中使用的劃分數據傳輸狀況的閥值TL和TH、調節范圍Range等參數都可以根據實際環境的需要來自行設定，通過合理參數設定使自適應調節策略達到滿意的效果。

4 Live555流媒體服務器設計

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

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

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

流媒體服務器架構設計如圖5所示。

圖5 流媒體服務器架構設計圖

流媒體服務器設計的重點就是實現實時視頻流的接收與發送，同時還要保持視頻傳輸的穩定。本文在流媒體服務器的設計時在接收緩沖區中加入了實時處理邏輯，有效的減小了實時視頻傳輸的時延，同時在緩沖區與數據源之間加入重傳模塊，并通過其與自適應調節模塊的協調配合，可以有效的保證視頻數據傳輸的穩定性，防止實時視頻播放過程中的突然中斷。

5 系統測試結果

測試結果表明，對流媒體服務器進行優化設計之后，時延明顯減小，可以滿足視頻傳輸系統對實時性的要求，同時視頻質量也有很大改善，如表1所示。優化之前視頻會經常出現大塊拉長的現象，優化之后偶爾也會出現拉長現象但是很快就會恢復，視頻流暢性更好。優化前后視頻畫面圖像如圖6、7所示。

表1 流媒體服務器優化前后對比

圖6 優化之前視頻畫面

圖7 優化之后視頻畫面

6 結束語

文中對Live555流媒體服務器進行優化設計，提出了一種實時化處理邏輯，實現了流媒體服務器的實時視頻傳輸，減小了實時視頻傳輸系統的時延。另外還提出了一種自適應重傳機制，當采集端數據不能及時傳到服務器時，自適應重傳機制能夠保持數據傳輸的連續性，防止因數據傳輸的不穩定造成播放端視頻播放的中斷，同時也能提高了視頻的質量。視頻數據傳輸的質量與網絡的狀況也有很大關系，可以在現有的基礎上對自適應重傳機制進行進一步研究，使其同時能根據當前網絡的狀況進行調節，更有效的提高視頻傳輸的質量。

[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解碼器實現[D].大連：大連理工大學，2011.

[4]高建水.基于RTSP協議的視頻點播系統設計[J].電子器件，2006，29（4）:1143-1146.

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

[6]劉暢欞，包杰，王寧國.基于Live555的網絡視頻監控技術與實現[J].現代電子科技，2012，12（12）：38-42.

[7]孫泉.支持H.264的實施流媒體服務器的設計與實現[D].北京：北京郵電大學，2010.

[8]黃帥.流媒體服務器在視頻數據傳輸中的應用[D].青島：青島科技大學，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的實時流媒體傳輸系統[J].計算機應用與軟件，2015，24（1）:56-59.

[11]劉大紅.基于RTSP流媒體服務器的設計與實現[D].西安：西安電子科技大學，2014.

[12]章民融.基于RTSP的流媒體視頻服務器的設計與實現[J].計算機應用與軟件，2006（8）:93-95.

[13]李校林.RTP/RTCP，RTSP在無線視頻監控系統的設計與實現[J].視頻應用與工程，2011，35（19）:89-92.

[14]涂兵，肖洪祥.流媒體服務器中音視頻幀封裝研究[J].計算機應用，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—），男，山東青島人，博士，教授。研究方向：無線通信。