面向并發(fā)服務(wù)的流媒體訪問控制技術(shù)研究

實(shí)時(shí)數(shù)據(jù)傳輸對于視頻播放具有非常重要的意義，在各種網(wǎng)絡(luò)特性中時(shí)延參數(shù)占有相當(dāng)?shù)姆萘俊ＭǔＵJ(rèn)為視頻這類應(yīng)用其時(shí)延要求小于20毫秒╩s），抖動(dòng)限制在4毫左?lt;SUP>[1][3]。盡管提高網(wǎng)絡(luò)帶寬可以改善網(wǎng)絡(luò)的吞吐量、傳輸延時(shí)等性能，由于視頻數(shù)據(jù)的高容量和視頻信源的高比特率特性，對于客戶端的服務(wù)質(zhì)量要求來說顯得微不足道。目前針對視頻服務(wù)質(zhì)量，從傳送層協(xié)議的使用、數(shù)據(jù)的壓縮/解壓、協(xié)同計(jì)算到單播/組播等多方面提出了許多措施?？紤]到網(wǎng)絡(luò)傳輸狀況的多樣性，本文重點(diǎn)討論服務(wù)器端的數(shù)據(jù)傳送調(diào)度控制，和并發(fā)服務(wù)的關(guān)鍵技術(shù)，盡可能地降低傳輸中的時(shí)延抖動(dòng)問題，提高并發(fā)服務(wù)質(zhì)量，文中最后給出了關(guān)鍵控制代碼和測試結(jié)果。

1        信源數(shù)據(jù)的并發(fā)傳輸模型

并發(fā)連接對于網(wǎng)絡(luò)視頻應(yīng)用來說，有別于以往的WEB頁面式服務(wù)和FTP服務(wù)，每個(gè)視頻數(shù)據(jù)流至少需要384kb/s的帶寬甚至更高。同時(shí)傳輸服務(wù)還需要具有一定的余量，防止并發(fā)客戶請求數(shù)達(dá)到峰值、或網(wǎng)絡(luò)短期過載現(xiàn)象。因此合適的服務(wù)模型、良好的服務(wù)策略是優(yōu)質(zhì)服務(wù)的保障。對即時(shí)的影像流壓縮與傳輸要求來說，在服務(wù)模型中還需要針對網(wǎng)絡(luò)系統(tǒng)的資源限制條件，即網(wǎng)絡(luò)帶寬采取適應(yīng)視頻傳輸?shù)牟呗裕员闾幚硗话l(fā)性事件。

另一個(gè)需要考慮的限制是服務(wù)器提供的并發(fā)連接數(shù)量以及等候處理的發(fā)送調(diào)用。因?yàn)椴l(fā)連接數(shù)量越多，所消耗的未分頁內(nèi)存池也越多；等候處理的發(fā)送調(diào)用越多，被鎖定的內(nèi)存頁面也越多，極易超過系統(tǒng)資源的極限。

1.1 服務(wù)器的視頻傳輸服務(wù)特點(diǎn)

視頻傳輸需要較寬的網(wǎng)絡(luò)帶寬，其視頻的壓縮編碼、傳輸信道和網(wǎng)絡(luò)協(xié)議的選擇、IP組播技術(shù)對傳輸質(zhì)量具有重要的影響作用?；谟?jì)算機(jī)網(wǎng)絡(luò)連接的視頻點(diǎn)播系統(tǒng)，其關(guān)鍵就在于多個(gè)站點(diǎn)視頻的網(wǎng)絡(luò)通信問題，要求做到傳輸時(shí)延盡可能小，盡可能少地占用現(xiàn)有的網(wǎng)絡(luò)帶寬，并具有較好的站點(diǎn)數(shù)量規(guī)模化特性。

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

1.2      服務(wù)器的并發(fā)服務(wù)技術(shù)

通?？蛻簦?wù)器間的通信過程首先是建立點(diǎn)到點(diǎn)的直接聯(lián)系方式，因此服務(wù)器的負(fù)載能力決定了視頻點(diǎn)播的并發(fā)容量。在客戶機(jī)/服務(wù)器傳輸方式中，在面向連接的通信模式下，服務(wù)器需要打開監(jiān)聽端口，監(jiān)聽網(wǎng)絡(luò)上其它客戶機(jī)向該服務(wù)器發(fā)出的連接請求，當(dāng)收到一個(gè)請求信號(hào)時(shí)與該客戶機(jī)建立一個(gè)連接，之后兩者進(jìn)行交互式的通信。這在客戶端請求較少，同時(shí)數(shù)據(jù)傳輸量不大的情況下傳輸延遲還可以忍受。

對于實(shí)時(shí)性要求較高的視頻應(yīng)用，一般采用無連接的通信模式。如MPEG-I按照1.5Mb/s傳輸在滿足觀看需要的情況下其幀數(shù)也要大于10幀以上。另外，當(dāng)多個(gè)用戶同時(shí)申請服務(wù)的時(shí)候，服務(wù)器建立連接分配資源等都需要產(chǎn)生延遲，也就是說對于用戶的響應(yīng)經(jīng)過逐漸積累延遲會(huì)越來越大。如果請求池不足的話，那么就會(huì)產(chǎn)生客戶的請求丟失。因此，同一時(shí)刻只能處理一個(gè)客戶請求的循環(huán)服務(wù)器方式不適合視頻點(diǎn)播。

如果采用并發(fā)服務(wù)方式[2]，在服務(wù)器端用主進(jìn)程去監(jiān)聽客戶機(jī)的連接請求，當(dāng)有客戶機(jī)的連接請求時(shí)通過創(chuàng)建線程的方式獨(dú)立處理客戶機(jī)通信，提高視頻傳輸?shù)膶?shí)時(shí)性。

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

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

從視頻應(yīng)用來說，影響視頻傳輸性能的根本原因在于視頻數(shù)據(jù)的連續(xù)傳送和用戶提交給服務(wù)器的請求無法及時(shí)響應(yīng)，超過了網(wǎng)絡(luò)資源節(jié)點(diǎn)容量或服務(wù)器的處理能力。這樣就造成網(wǎng)絡(luò)系統(tǒng)的數(shù)據(jù)包時(shí)延增加、丟棄概率增大、上層應(yīng)用系統(tǒng)性能下降等。主要表現(xiàn)在以下幾方面：

⑴ 并發(fā)連接數(shù)決定系統(tǒng)內(nèi)存資源的消耗，并與CPU的處理能力密切相關(guān)。

⑵ 視頻服務(wù)要求服務(wù)器盡快地把數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送，盡量減少對連接請求的處理延遲，以免服務(wù)請求的重發(fā)和丟失。

⑶ 物理鏈路的實(shí)際承載能力也影響并發(fā)連接的處理能力。根據(jù)香農(nóng)信息理論，任何信道帶寬最大值即信道容量:

C=Blog2(1+S/N)（N為信道白噪聲的平均功率，S為信源節(jié)點(diǎn)的平均功率,B為信道帶寬）。所有信源節(jié)點(diǎn)發(fā)送的速率R必須小于或等于信道容量C。如果R>C，則在理論上無差錯(cuò)傳輸就是不可能的，所以服務(wù)器與網(wǎng)絡(luò)的聯(lián)結(jié)處會(huì)形成傳輸瓶頸。

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

隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大和用戶數(shù)的激增，數(shù)據(jù)流傳輸更趨于頻繁，線程數(shù)量不可能無限制增加。如果服務(wù)器和客戶之間沒有緩沖余地必然會(huì)出現(xiàn)丟棄數(shù)據(jù)包的情況。當(dāng)數(shù)據(jù)包丟棄時(shí)，源節(jié)點(diǎn)端會(huì)超時(shí)、重傳該包。由于沒有得到確認(rèn)，源節(jié)點(diǎn)端只能保留數(shù)據(jù)包，結(jié)果緩存會(huì)進(jìn)一步消耗。因此，采用合理的算法與機(jī)制,按需分配傳輸線程占用的網(wǎng)絡(luò)資源對于網(wǎng)絡(luò)傳輸至關(guān)重要。值得指出的是，帶寬保證是視頻實(shí)時(shí)傳輸?shù)幕A(chǔ)，帶寬如果完全均分，每個(gè)站點(diǎn)都得到總帶寬的1/n（設(shè)存在n個(gè)站點(diǎn)），顯然不能適應(yīng)實(shí)際的帶寬需求；因此，有必要根據(jù)重要性、實(shí)時(shí)性分配帶寬使用的優(yōu)先級，利用“流控技術(shù)”達(dá)到帶寬管理的有效性、確保并發(fā)任務(wù)的順利實(shí)施。[!--empirenews.page--]

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

1.3 基于實(shí)時(shí)傳輸?shù)膮f(xié)議機(jī)制

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

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

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

RTCP單獨(dú)運(yùn)行在底層協(xié)議上監(jiān)視服務(wù)質(zhì)量并與會(huì)話者傳遞信息，RTCP是由接收方向發(fā)送的報(bào)文，它負(fù)責(zé)監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量、通信帶寬以及網(wǎng)上傳送的信息，并將這些信息反饋給發(fā)送端，并提供QoS的檢測，提供不同媒體間的同步信息和會(huì)話參與者的標(biāo)識(shí)信息。

基于事件處理的多線程多緩沖區(qū)機(jī)制顯得更勝一籌。但是當(dāng)在廣域網(wǎng)中進(jìn)行視頻數(shù)據(jù)傳輸時(shí)，此時(shí)的傳輸性能極大地取決于可用的帶寬，由于TCP是面向連接的傳輸層協(xié)議，它的重傳機(jī)制和擁塞控制機(jī)制，將使網(wǎng)絡(luò)狀況進(jìn)一步惡化，從而帶來災(zāi)難性的延時(shí)。同時(shí)，在這種網(wǎng)絡(luò)環(huán)境下，通過TCP傳輸?shù)囊曨l數(shù)據(jù)，在接收端重建、回放時(shí)，斷點(diǎn)非常明顯，體現(xiàn)為明顯的斷斷續(xù)續(xù)，傳輸?shù)膶?shí)時(shí)性和傳輸質(zhì)量都無法保障。相對而言，采用RTP傳輸?shù)囊曨l數(shù)據(jù)的實(shí)時(shí)性和傳輸質(zhì)量就要好得多。

2 并發(fā)服務(wù)的任務(wù)調(diào)度策略

面對越來越巨大的流應(yīng)用需求，系統(tǒng)必須擁有良好的可伸縮性。隨著業(yè)務(wù)的增加和用戶的增多，系統(tǒng)需要靈活地增加現(xiàn)場直播流的數(shù)量，并通過增加帶寬集群和接近最終用戶端的邊緣流媒體服務(wù)器的數(shù)量，增加并發(fā)用戶的數(shù)量，不斷滿足用戶對系統(tǒng)的擴(kuò)展要求。

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

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

調(diào)度的任務(wù)就是合理劃分時(shí)間片和循環(huán)執(zhí)行各個(gè)線程，并能有效地監(jiān)測線程阻塞和消除。每個(gè)線程都占用一部分CPU時(shí)間片，每個(gè)時(shí)間片上一個(gè)線程運(yùn)行，另一個(gè)時(shí)間片又可能是另外的線程在工作。

根據(jù)視頻流的傳送要求，并發(fā)服務(wù)的優(yōu)先級調(diào)度方式不適合專用于視頻服務(wù)的工作，這會(huì)造成優(yōu)先級高的視頻流強(qiáng)占低優(yōu)先級的視頻流服務(wù)。因此，為了達(dá)到每個(gè)視頻流服務(wù)的公平性，采用帶有可變加權(quán)的循環(huán)調(diào)度。其循環(huán)順序由申請服務(wù)的先后次序決定，以服務(wù)的時(shí)延最小進(jìn)行調(diào)整控制，實(shí)現(xiàn)各個(gè)服務(wù)的最小允許延遲保證優(yōu)質(zhì)服務(wù)。

3 實(shí)現(xiàn)方案與測試驗(yàn)證

并發(fā)操作在同一時(shí)刻能夠處理多個(gè)客戶請求，從RTP/RTCP協(xié)議使用的角度來說，其實(shí)現(xiàn)方法也有多種，如服務(wù)器對每個(gè)接收到的客戶連接創(chuàng)建一個(gè)線程處理；或者預(yù)先創(chuàng)建多個(gè)線程，由這些線程處理請求。

當(dāng)然，使用多處理硬件更能較好地實(shí)現(xiàn)多任務(wù)的并發(fā)操作，特別是對于Linux使用多個(gè)處理器處理不同的線程時(shí)，并發(fā)效果要好的多。值得注意的是防止多個(gè)線程在單個(gè)處理器上造成瓶頸，而其它處理器卻處于空閑狀態(tài)，當(dāng)然其它并發(fā)方法有時(shí)也會(huì)造成類似的問題。這方面有賴于操作系統(tǒng)的性能，對Linux 2.4來說其缺省的“內(nèi)核線程”可以很好地調(diào)度線程，并將這些線程分配給不同的CPU。

3.1 實(shí)時(shí)傳輸?shù)男畔⒖刂?/p>

線程建立通信連接關(guān)系后，根據(jù)RTP提供的時(shí)間信息實(shí)現(xiàn)流同步，通過RTCP反饋的信息進(jìn)行數(shù)據(jù)流控制并動(dòng)態(tài)調(diào)整傳輸率，保證數(shù)據(jù)延遲符合預(yù)定要求。

服務(wù)器監(jiān)聽端口，根據(jù)實(shí)際客戶請求量確定請求隊(duì)列的允許最大連接數(shù)目。

accept(客戶請求)

｛  提取并分析請求隊(duì)列中的某一任務(wù)；

尋找具有相同視頻信號(hào)標(biāo)志的任務(wù)，使用組播技術(shù)設(shè)置ip地址由子進(jìn)程處理播放；否則后置單位時(shí)間⊿t。處理時(shí)間⊿t的任務(wù)(Proc_Client())。｝

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

{   CreateThread() //創(chuàng)建線程

{   讀出當(dāng)前時(shí)間，并將當(dāng)前時(shí)間寫入通信文件描述符；

比較RTCP中資源信息與現(xiàn)有資源的差異，調(diào)整數(shù)據(jù)包發(fā)送大小和發(fā)送速度；如果子進(jìn)程的數(shù)據(jù)傳送完，則關(guān)閉通信文件描述符；反之，繼續(xù)傳送。}}[!--empirenews.page--]

UDP層檢查其目的端口（如果其UDP套接口已連接，也可能檢查源端口），將數(shù)據(jù)報(bào)放到相應(yīng)套接口的接收隊(duì)列。如果需要，就喚醒線程，由線程讀取這個(gè)新接收的數(shù)據(jù)報(bào)。

3.2 線程的調(diào)度控制

線程間通過互斥鎖，實(shí)現(xiàn)循環(huán)控制，即在線程處理視頻數(shù)據(jù)前通過互斥變量、信號(hào)燈加鎖，主要代碼如下：

sem_wait();

pthread_mutex_lock();

……

thread_next_flag=true;//設(shè)置下一個(gè)可執(zhí)行線程標(biāo)志

pthread_mutex_unlock();

sem_post();

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

按照上述策略，在Linux 9.0系統(tǒng)下編程實(shí)現(xiàn)了數(shù)據(jù)的傳輸，服務(wù)器的配置賽揚(yáng)為2.0GHz,網(wǎng)卡為10/100M自適應(yīng)。接收端為賽揚(yáng)1.0GHz，網(wǎng)卡同樣為10/100M，通過交換機(jī)互聯(lián)。服務(wù)器預(yù)創(chuàng)建5個(gè)傳輸服務(wù)線程，圖中為兩個(gè)接收端的數(shù)據(jù)接收延遲情況，均傳送2000個(gè)數(shù)據(jù)包，從統(tǒng)計(jì)的結(jié)果圖來看，除了起始端出現(xiàn)較大的延遲外，延遲抖動(dòng)均沒有過大的變化。但在沒有使用本文提出的調(diào)度控制的情況下，常常出現(xiàn)時(shí)延的急劇變化，即某一數(shù)據(jù)流出現(xiàn)了較大時(shí)延。

因此，本文的并發(fā)傳輸調(diào)度達(dá)到了使用要求，效果比較令人滿意。

圖1 多線程數(shù)據(jù)傳送調(diào)度控制測試結(jié)果

4 結(jié)論

由于視頻數(shù)據(jù)傳輸需要較大的數(shù)據(jù)吞吐量，容易出現(xiàn)網(wǎng)絡(luò)丟包和延遲較大的情況，以致造成接收端視頻抖動(dòng)和明顯滯后。視頻數(shù)據(jù)傳輸時(shí)出現(xiàn)頻繁抖動(dòng)，最終影響視頻的服務(wù)質(zhì)量。

本文基于流媒體技術(shù)和并發(fā)調(diào)度方式，提出了視頻傳輸?shù)木C合方案，利用多線程技術(shù)實(shí)現(xiàn)多點(diǎn)視頻數(shù)據(jù)并發(fā)傳輸；利用調(diào)度控制技術(shù)實(shí)現(xiàn)以延遲抖動(dòng)最小的服務(wù)。此外結(jié)合其它多路復(fù)用技術(shù)，分布式結(jié)構(gòu)以及組播等方式可支持更多的連接,減少不必要的重疊發(fā)送，減輕系統(tǒng)和網(wǎng)絡(luò)的負(fù)擔(dān)，提高服務(wù)器CPU資源和網(wǎng)絡(luò)帶寬的利用率，對改善視頻數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性、并發(fā)性，實(shí)現(xiàn)網(wǎng)絡(luò)視頻的多點(diǎn)實(shí)時(shí)傳輸、網(wǎng)絡(luò)多點(diǎn)實(shí)時(shí)監(jiān)控等方面具有特別重要的實(shí)際意義。

參   考   文   獻(xiàn)

[1]  胡道元.《計(jì)算機(jī)網(wǎng)絡(luò)（高級）》. 北京：清華大學(xué)出版社，1999.8 P107。

[2] 張斌 高波等編著《Linux網(wǎng)絡(luò)編程》北京：清華大學(xué)出版社，2000.1.1 P2-8。

[3] 鐘玉琢.向哲.沈洪《流媒體和視頻服務(wù)器》.清華大學(xué)出版社.2003.6.1

[4] RFC 1889,"RTP: A Transport Protocol for Real-Time Applications", 1996.1

[5] http://www-900.cn.ibm.com/developerworks/cn/linux/sdk/rt/part7/indexeng.htm

[6] RunTime: Synchronizing processes and threads http://www-900.ibm.com/developerWorks/cn/linux/sdk/rt/part5/index_eng.shtml

[7] http://www.douzhe.com/linux/13code/13067.htm

ce="宋體">更多計(jì)算機(jī)與外設(shè)信息請關(guān)注：21ic計(jì)算機(jī)與外設(shè)頻道