流媒體訪問技術的探索與實踐

摘要：如今，網絡資源尤其是視頻在教學中已經廣泛應用，但常常出現一些影響教學的因素。本文采用一種基于實時協議的多媒體數據流并發服務控制模型，介紹了數據并發傳送的調度控制，由實時協議的反饋機制動態調整控制參數，達到平滑時延的目的。最后通過對時延參數的測試，說明這一數據流控制方式的合理性，同時該方法也適用于網絡視頻的多點實時傳輸、網絡多點實時監控，有較高的應用價值。

關鍵詞：實時數據傳輸；流媒體技術；訪問控制；并發調度

The Exploration and Implementation of Streaming Media Access Technology

Xu Xueyu

（Shenyang Polytechnic CollegeShenyangLiaoning 110045）

Abstract: Now，network resources and video in particular have been widely utilized in teaching， but some factors often appear influencing teaching in its progress，the article adopted a sort of multimedia dataflow concurrent service control models based on real-time protocol，introduced the scheduling control of concurrent data transmission，adjusting control parameters dynamically through the feedback system of real-time protocol，achieving the target of smooth delay.Eventually through the test to delay parameter， the rationality of such dataflow control method has been illustrated，meanwhile the method also adapts to multipoint real-time transmission of network video，multipoint real-time network monitoring，containing high application value.

Keywords: real-time data transmission;streaming media technology;access control;concurrent scheduling

實時數據傳輸對于視頻播放具有非常重要的意義，在各種網絡特性中，時延參數占有相當的份量。通常認為，視頻這類應用其時延要求小于20毫秒，抖動限制在4毫秒左右。盡管提高網絡帶寬可以改善網絡的吞吐量、傳輸延時等性能，但由于視頻數據的高容量和視頻信源的高比特率特性，對于客戶端的服務質量要求來說，顯得微不足道。目前針對視頻服務質量，從傳送層協議的使用、數據的壓縮/解壓、協同計算到單播/組播等多方面提出了許多解決方案。

1 信源數據的并發傳輸模型

并發連接對于網絡視頻應用來說，有別于以往的WEB頁面式服務和FTP服務，每個視頻數據流至少需要384kb/s的帶寬甚至更高。同時傳輸服務還需要具有一定的余量，防止并發客戶請求數達到峰值、網絡短期過載等現象。因此，合適的服務模型、良好的服務策略是優質服務的保障。對即時的影像流壓縮與傳輸要求來說，在服務模型中還需要針對網絡系統的資源限制條件，即網絡帶寬采取適應視頻傳輸的措施，以便處理突發性事件。

1.1 服務器的視頻傳輸服務特點

視頻傳輸需要較大的網絡帶寬，視頻的壓縮編碼、傳輸信道和網絡協議的選擇、IP組播技術對傳輸質量都具有重要的影響。基于計算機網絡連接的視頻點播系統，關鍵在于多個站點視頻的網絡通信問題，要求做到傳輸時延盡可能小，盡可能少地占用現有的網絡帶寬，并具有較好的站點數量規模化特性。

視頻服務器對于用戶的請求，需要在較短的時間間隔內響應并傳送所要求的視頻數據，同時隨時準備響應新的請求。因而，視頻服務器的性能直接決定系統的總體性能，為了能同時響應多個用戶的服務請求，視頻服務器需要調度服務，并具備接納控制、請求處理、數據檢索、按流傳送等多種功能，提供實時、連續穩定的視頻流，以確保用戶請求獲得有效滿足。再者，視頻服務器還需要提供交互服務，如快進和快倒等功能，因此視頻服務器必須滿足視頻流特性使用中的各種要求。

1.2 服務器的并發服務技術

通常，客戶——服務器間的通信過程首先是建立點到點的直接聯系方式，因此服務器的負載能力決定了視頻點播的并發容量。在客戶機/服務器傳輸方式中，在面向連接的通信模式下，服務器需要打開監聽端口，監聽網絡上其它客戶機向該服務器發出的連接請求，當收到一個請求信號時，與該客戶機建立一個連接，之后兩者進行交互式的通信。這在客戶端請求較少，同時數據傳輸量不大的情況下傳輸延遲還可以忍受。

對于實時性要求較高的視頻應用，一般采用無連接的通信模式。如MPEG-I按照1. 5Mb/s傳輸在滿足觀看需要的情況下其幀數也要大于10幀以上。另外，當多個用戶同時申請服務的時候，服務器建立連接分配資源等都需要產生延遲。也就是說，用戶的響應經過逐漸積累，延遲會越來越大。如果請求池不足的話，那么就會產生客戶的請求丟失等現象。因此，同一時刻只能處理一個客戶請求的循環服務器方式不適合視頻點播。如果采用并發服務方式，在服務器端用主進程去監聽客戶機的連接請求，當有客戶機的連接請求時，通過創建線程的方式獨立處理客戶機通信，提高視頻傳輸的實時性。

視頻數據的并發傳輸，實質上依賴于服務器中的傳輸線程。服務器的操作以建立相應的線程實現服務為目的，這種服務模式非常適合復雜的多任務請求。從計算機操作系統運行的角度來說，在典型的單處理器主機上，任務實際上并不是同時執行的。內核中稱為調度程序的部分將工作換進換出，從而讓所有工作都獲得一輪執行。在同一個時間間隔內，并發模型常常基于事件的編程實現。

通常情況下，線程數量取決于應用程序的特定需要，理想情況下線程數量與處理器數量相當為好，雖然線程數量無法保證傳輸質量，但線程太少又會造成傳輸效率低，特別是用戶數量較多的情況下更為明顯。

從視頻應用來說，影響視頻傳輸性能的根本原因在于視頻數據的連續傳送和用戶提交給服務器的請求無法及時響應，超過了網絡資源節點容量或服務器的處理能力。這樣就造成網絡系統的數據包時延增加、丟棄概率增大、上層應用系統性能下降等。主要表現在以下幾方面：

⑴ 并發連接數決定系統內存資源的消耗，并與CPU的處理能力密切相關；

⑵ 視頻服務要求服務器盡快地把數據通過網絡發送，盡量減少對連接請求的處理延遲，以免服務請求的重發和丟失；

⑶ 物理鏈路的實際承載能力也影響并發連接的處理能力。根據香農信息理論，任何信道帶寬最大值即信道容量：C=Blog2(1+S/N)（N為信道白噪聲的平均功率，S為信源節點的平均功率，B為信道帶寬）。所有信源節點發送的速率R必須小于或等于信道容量C。如果R>C，則在理論上無差錯傳輸就是不可能的，所以服務器與網絡的聯結處會形成傳輸瓶頸；

⑷ 交換機或路由器的處理能力弱：如果路由器的CPU在執行排隊緩存、更新路由表等功能時，處理速度無法與高速鏈路匹配，就會造成服務失效。

隨著網絡規模的擴大和用戶數的激增，數據流傳輸更趨于頻繁。如果服務器和客戶之間沒有緩沖余地，必然會出現丟棄數據包的情況。當數據包丟棄時，源節點端會超時、重傳該包。由于沒有得到確認，源節點端只能保留數據包，結果緩存會進一步消耗。因此，采用合理的算法與機制，按需分配傳輸線程占用的網絡資源對于網絡傳輸至關重要。值得指出的是，帶寬保證是視頻實時傳輸的基礎，帶寬如果完全均分，每個站點都得到總帶寬的1/n（設存在n個站點），顯然不能適應實際的帶寬需求。因此，有必要根據重要性、實時性分配帶寬使用的優先級，利用“流控技術”達到帶寬管理的有效性、確保并發任務的順利實施。

采用單播、廣播和組播可以減輕服務器負擔，也能提高并發數。組播的多點投遞方式，使所有機器能夠接收每個分組的同一拷貝，減少了資源浪費。而常規的點對點通信方式下，N個視頻站點的視頻傳輸至少要重復發送N-1次相同的數據包，發送時延大，而且隨著播放站點數量增長，時延就會迅速增長，這樣就不能適應要求短時延的多點視頻傳輸。

1.3 基于實時傳輸的協議機制

由于TCP需要較多的開銷，它的重傳機制和擁塞控制機制（Congestion Control Mechanism）不可避免地產生了傳輸延時和占用了較多的網絡帶寬，故不適合傳輸實時視頻音頻。在視音頻的流式傳輸實現方案中，一般采用HTTP/TCP來傳輸控制信息，用RTP/UDP來傳輸實時聲音數據。

實時傳輸協議RTP（Real-time transport protocol）[4]是用于internet上針對多媒體數據流的一種傳輸協議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。通常利用低層的UDP協議對實時視音頻數據進行組播（Multicast）或單播（Unicast），從而實現多點或單點視音頻數據的傳輸，當然RTP也可以在TCP或ATM等其他協議之上工作。RTP本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，而是依靠RTCP提供這些服務保證實時傳輸的操作。

實時傳輸控制協議RTCP(Real-time transport control protocol)和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTCP是RTP的控制協議，RTP和RTCP配合使用能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。

RTCP單獨運行在底層協議上監視服務質量并與會話者傳遞信息，RTCP是由接收方向發送的報文，它負責監視網絡的服務質量、通信帶寬以及網上傳送的信息，并將這些信息反饋給發送端，并提供QoS的檢測，提供不同媒體間的同步信息和會話參與者的標識信息。

基于事件處理的多線程多緩沖區機制顯得更勝一籌。但是當在廣域網中進行視頻數據傳輸時，此時的傳輸性能極大地取決于可用的帶寬，由于TCP是面向連接的傳輸層協議，它的重傳機制和擁塞控制機制，將使網絡狀況進一步惡化，從而帶來災難性的延時。同時，在這種網絡環境下，通過TCP傳輸的視頻數據，在接收端重建、回放時，斷點非常明顯，體現為明顯的斷斷續續，傳輸的實時性和傳輸質量都無法保障。相對而言，采用RTP傳輸的視頻數據的實時性和傳輸質量就要好得多。

2 并發服務的任務調度策略

面對越來越巨大的流應用需求，系統必須擁有良好的可伸縮性。隨著業務的增加和用戶的增多，系統需要靈活地增加現場直播流的數量，并通過增加帶寬集群和接近最終用戶端的邊緣流媒體服務器的數量，增加并發用戶的數量，不斷滿足用戶對系統的擴展要求。

通常情況下，一個視頻流的播放準備需要的準備時間是比較長的。按照進程方式提供服務的話，如果不斷接收到客戶的請求，同時又不斷地創建子進程處理，必然會影響客戶的接收，其服務器并發數也大打折扣。因此，采用“預創建（prefork）”技術可以緩解這種情況。服務器事先創建一定數目的子進程，每個子進程分別接受連接隊列中已建立連接的客戶連接。這樣，就由子進程快速響應并處理客戶請求。

并發與調度密切相關，如何分配任務給 CPU、如何調度任務直接影響到效率和可行性。效率較高的并發方法之一是“多線程”，也就是“線程化”。但線程化并不是唯一的并發構造，它的實現依賴于資源的可用情況并有一定的局限性。 文獻 [5]中提到了多種可行的并發應用模型，除線程化外，還有多處理、協同例程和基于事件的編程，以及連續（continuation）、生成器和其它一些構造。

調度的任務就是合理劃分時間片和循環執行各個線程，并能有效地監測線程阻塞和消除。每個線程都占用一部分CPU時間片，每個時間片上一個線程運行，另一個時間片又可能是另外的線程在工作。

根據視頻流的傳送要求，并發服務的優先級調度方式不適合專用于視頻服務的工作，這會造成優先級高的視頻流強占低優先級的視頻流服務。因此，為了達到每個視頻流服務的公平性，采用帶有可變加權的循環調度。其循環順序由申請服務的先后次序決定，以服務的時延最小進行調整控制，實現各個服務的最小允許延遲保證優質服務。

3 實現方案與測試驗證

并發操作在同一時刻能夠處理多個客戶請求，從RTP/RTCP協議使用的角度來說，其實現方法也有多種，如服務器對每個接收到的客戶連接創建一個線程處理；或者預先創建多個線程，由這些線程處理請求。

當然，使用多處理硬件更能較好地實現多任務的并發操作，特別是對于Linux使用多個處理器處理不同的線程時，并發效果要好的多。值得注意的是防止多個線程在單個處理器上造成瓶頸，而其它處理器卻處于空閑狀態，當然其它并發方法有時也會造成類似的問題。這方面有賴于操作系統的性能，對Linux 2. 4來說其缺省的“內核線程”可以很好地調度線程，并將這些線程分配給不同的CPU。

3.1 實時傳輸的信息控制

線程建立通信連接關系后，根據RTP提供的時間信息實現流同步，通過RTCP反饋的信息進行數據流控制并動態調整傳輸率，保證數據延遲符合預定要求。

服務器監聽端口，根據實際客戶請求量確定請求隊列的允許最大連接數目。

accept(客戶請求)

｛提取并分析請求隊列中的某一任務；

尋找具有相同視頻信號標志的任務，使用組播技術設置ip地址由子進程處理播放；否則后置單位時間⊿t。處理時間⊿t的任務(Proc_Client())。｝

while(客戶機與服務器成功連接——成功返回通信文件描述符)

{CreateThread() //創建線程

{讀出當前時間，并將當前時間寫入通信文件描述符；

比較RTCP中資源信息與現有資源的差異，調整數據包發送大小和發送速度；如果子進程的數據傳送完，則關閉通信文件描述符；反之，繼續傳送。}}

UDP層檢查其目的端口（如果其UDP套接口已連接，也可能檢查源端口），將數據報放到相應套接口的接收隊列。如果需要，就喚醒線程，由線程讀取這個新接收的數據報。

3. 2 線程的調度控制

線程間通過互斥鎖，實現循環控制，即在線程處理視頻數據前通過互斥變量、信號燈加鎖，主要代碼如下：

sem_wait();

pthread_mutex_lock();

……

thread_next_flag=true;//設置下一個可執行線程標志

pthread_mutex_unlock();

sem_post();

為了實現有效的服務，需要保證視頻數據流的傳輸具有相對的數據完整性。接收端常根據數據的到達情況通過RTP/RTCP協議的信息反饋，為服務器提供數據包接收情況的質量統計反饋信息和QoS檢測的資料；對于接收端而言，數據的存放需要占用一定數量的緩存，以承受 網絡 帶寬波動，并在傳輸中增加一定冗余信息來重建丟失或受損的數據，減少數據重傳。

按照上述策略，在Linux 9. 0系統下編程實現了數據的傳輸，服務器的配置賽揚為2. 0GHz，網卡為10/100M自適應。接收端為賽揚1. 0GHz，網卡同樣為10/100M，通過交換機互聯。服務器預創建5個傳輸服務線程，圖中為兩個接收端的數據接收延遲情況，均傳送2000個數據包，從統計的結果圖來看，除了起始端出現較大的延遲外，延遲抖動均沒有過大的變化。但在沒有使用本文提出的調度控制的情況下，常常出現時延的急劇變化，即某一數據流出現了較大時延。

因此，本文的并發傳輸調度達到了使用要求，效果比較令人滿意。

4 結論

由于視頻數據傳輸需要較大的數據吞吐量，因此容易出現網絡丟包和延遲較大等情況，以致造成接收端視頻抖動和明顯滯后。視頻數據傳輸時出現頻繁抖動，最終影響視頻的服務質量。

本文基于流媒體技術和并發調度方式，提出了視頻傳輸的綜合解決方案，利用多線程技術實現多點視頻數據并發傳輸；利用調度控制技術實現以延遲抖動最小的服務。此外結合其它多路復用技術，分布式結構以及組播等方式可支持更多的連接，減少不必要的重疊發送，減輕系統和網絡的負擔，提高服務器CPU資源和網絡帶寬的利用率，對改善視頻數據傳輸的實時性、并發性，實現網絡視頻的多點實時傳輸、網絡多點實時監控等方面具有特別重要的意義。

參考文獻

[1]胡道元.計算機網絡高級[D].北京：清華大學出版社，1999.8.

[2]張斌，高波.Linux網絡編程[D].北京：清華大學出版社，2000.1.1.

[3]鐘玉琢，向哲，沈洪.流媒體和視頻服務器[D].北京：清華大學出版社.2003.6.1

[4]王宇杰，王鋒，楊文賓.計算機網絡訪問控制技術研究[J].現代計算機.2010.7

[5]閔兆娥.流媒體技術及其在高等教育中的應用[J].科技情報技術與開發.2006.11

[6]歐曉鷗.IPTV(網絡電視)的技術研究[J].電子工程師.2007.12