實時視頻數(shù)據(jù)傳輸中接收端緩存區(qū)的設計

蓋曉娜，陳名松，曾欣旖

（桂林電子科技大學 信息與通信學院，廣西 桂林 541004）

Internet是人們學習、生活、工作中獲取和傳輸信息的重要途徑，而網(wǎng)絡應用對數(shù)據(jù)傳輸?shù)膶崟r性提出更高要求，因此，需要新型高速的網(wǎng)絡協(xié)議支持。RTP/RTCP協(xié)議、RTSP協(xié)議、RSVP協(xié)議協(xié)同合作，共同完成網(wǎng)絡實時多媒體應用的數(shù)據(jù)傳輸和控制、資源預留以及服務質量保證等工作。其中RTP/RTCP協(xié)議是實時視頻傳輸重要的協(xié)議之一。實時視頻數(shù)據(jù)的傳輸過程中，如果接收端讀數(shù)據(jù)者和寫數(shù)據(jù)者的速度不同，則會造成讀寫負荷不均衡，導致數(shù)據(jù)丟失或系統(tǒng)出錯。而緩沖技術可解決數(shù)據(jù)讀寫速率不一致的矛盾，提高實時傳輸系統(tǒng)的工作效率[1]。

1 RTP/RTCP協(xié)議

實時傳輸協(xié)議 RTP（Real-time Transport Protocol）是應用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP定義為在一對一或一對多的傳輸情況下工作，用于提供時間信息和實現(xiàn)流同步[2]。RTP協(xié)議采用應用幀原理，只提供基本的協(xié)議框架，開發(fā)者可以針對具體應用進行擴展。該協(xié)議位于UDP協(xié)議之上，在功能上獨立于其下面的傳輸層和網(wǎng)絡層，但不能單獨作為一個層次存在，通常是利用UDP協(xié)議對實時音視頻數(shù)據(jù)進行組播或單播，從而實現(xiàn)多點或單點音視頻數(shù)據(jù)的傳輸。

實時傳輸控制協(xié)議RTCP（Real-time Control Protocol）是RTP協(xié)議的控制部分，用于擁塞控制和流控制。在RTP會話期間，會話中的每個用戶定期發(fā)送RTCP包反饋統(tǒng)計信息（如發(fā)包數(shù)、丟包數(shù)、時延等），發(fā)送方據(jù)此調節(jié)發(fā)送速率。RTP和RTCP配合使用，為音視頻數(shù)據(jù)的實時傳輸提供Qos保障[3]。

2 實時視頻傳輸系統(tǒng)的結構

圖1是實時視頻傳輸系統(tǒng)的結構框圖。視頻數(shù)據(jù)傳輸時的視頻幀較大，而RTP對所傳送報文的大小有限制，因此需對其進行拆幀封裝。實際工作中，通常把1 KB作為視頻數(shù)據(jù)傳輸?shù)腗TU值，將大于MTU值的視頻數(shù)據(jù)進行分割（即切幀）后封裝打包。發(fā)送端服務器將壓縮打包后的視頻數(shù)據(jù)按照RTP的報文格式裝入RTP報文的數(shù)據(jù)負載段，同時配置RTP報文頭部的時間戳、同步信息、序列號等重要參數(shù)，此時的數(shù)據(jù)報已具有時間特征，即已被“流化”[4]。在UDP/TCP層，RTP報文作為負載數(shù)據(jù)裝入UDP/TCP報文中，由IP層完成最后的報文頭部配置，實現(xiàn)網(wǎng)絡傳輸。

圖1 實時視頻傳輸系統(tǒng)的結構

由于網(wǎng)絡是動態(tài)變化的，各數(shù)據(jù)包的傳輸路徑不同，到達接收端的時間也不同，有可能后發(fā)送的先到達。所以接收端需重組視頻切幀，重組過程必須是對發(fā)送端的報文封裝和打包標準進行逆變換。在重組過程中采取緩沖技術以減少延遲和抖動的影響。接收端綜合RTP數(shù)據(jù)包和SR包計算出數(shù)據(jù)包的到達時延和丟失率，形成RTCP包（RR包）反饋給發(fā)送端，發(fā)送端根據(jù)RR包提供的網(wǎng)絡信息調整發(fā)送策略[5]。

3 實時緩沖區(qū)的設計與實現(xiàn)

在接收端采用環(huán)形緩沖區(qū)重組視頻幀。環(huán)形緩沖區(qū)通常有1個讀指針和1個寫指針。其中，讀指針指向環(huán)形緩沖區(qū)中可讀取的數(shù)據(jù)，寫指針指向環(huán)形緩沖區(qū)中可寫入的緩沖區(qū)。通過移動讀指針和寫指針實現(xiàn)緩沖區(qū)的數(shù)據(jù)讀取和寫入。通常情況下，環(huán)形緩沖區(qū)的讀寫指針同一時刻不會在同一內(nèi)存區(qū)操作，因此讀寫數(shù)據(jù)過程中不會出現(xiàn)因收到的報文無法及時寫入而丟棄的現(xiàn)象，無需采用互斥同步處理。但應注意要對判定滿幀操作指針與寫線程操作之間進行一些同步處理，因為視頻緩存區(qū)的讀線程中涉及到對視頻滿幀的判斷，有可能與寫線程發(fā)生沖突。但該同步處理不會影響緩存區(qū)的工作效率，因為判定滿幀操作的時間比讀寫指針操作時間短。

如圖2所示，寫指針從時刻1寫入數(shù)據(jù)，到時刻2儲存滿幀。滿幀判定指針從讀指針處開始，不斷循環(huán)判斷是否滿幀，具體判定方法如下：首先，分別設計視頻幀頭部起始和幀尾部分為4字節(jié)的0X00000000和4字節(jié)的0XFFFFFFFF，作為視頻數(shù)據(jù)開始和結束標志。判定指針先判定讀指針后4字節(jié)是否為0X00000000，若是則判定為幀起始處，繼續(xù)讀2字節(jié)的數(shù)據(jù)，可推算出該視頻幀的實際長度等于該數(shù)據(jù)減去16字節(jié)的幀頭幀尾。根據(jù)幀實際長度移動判定指針到幀尾部，判定是否為0XFFFFFFFF。如果是則判定為滿幀，可直接從讀指針位置讀取視頻幀信息。在寫數(shù)據(jù)包中，如果接收到亂序數(shù)據(jù)包，則直接丟棄，同時寫指針返回到本幀起始位置。

圖2 環(huán)形視頻緩沖區(qū)

圖2中，如果在時刻3收到亂序報文，則直接丟棄該報文，寫指針返回時刻2，等到下一切幀的0報文到達后重新開始寫入。在寫指針到達緩沖區(qū)尾部時刻4時，可繼續(xù)將剩余的視頻數(shù)據(jù)填充到緩沖區(qū)頭部，依此類推[6]緩沖區(qū)讀寫線程軟件流程如圖3所示。

圖3 緩沖區(qū)讀寫線程軟件流程

4 結束語

在通信程序中，環(huán)形緩沖區(qū)經(jīng)常被用作數(shù)據(jù)結構來存放通信中發(fā)送和接收的數(shù)據(jù)。其讀寫指針在同一時刻不會操作于同一內(nèi)存區(qū)，無需采用互斥同步處理，環(huán)形緩沖區(qū)可有效利用存儲器空間，在實時傳輸中具有重要作用。

[1]黃毅封.支持阻塞和非阻塞模型且線程安全的環(huán)形緩沖的設計與實現(xiàn)—環(huán)形緩沖，攻克高級緩沖技術的關鍵[J].電腦編程技巧與維護，2003（11）：2-3.

[2]Colin Perkins.RTP：audio and video for the internet[M].New york：Addison，2003.

[3]Schulzrinne H， Casner S，F(xiàn)rederick R，et al.VRTP：a transport protocol for real-time applications[J].RFC 1889，1996（1）：256-258.

[4]李燕嶺，馬瑞芳，左 力.基于RTP/RTCP的實時視頻數(shù)據(jù)傳輸模型及實現(xiàn)[J].微電子學與計算機，2005，23（8）：138-142.

[5]許花榮，李名世.基于RTP的實時視頻傳輸系統(tǒng)[J].計算機工程與設計，2005，26（4）：876-878

[6]陳 鋒.基于VOIP的PDA可視電話終端的設計與實現(xiàn)[D].桂林：桂林電子科技大學，2009.