【正文】 務(wù)器復(fù)雜；后者如MMS（MicrosoftMediaServer）、RTSP等。這些協(xié)議在有防火墻時可能出現(xiàn)問題，導(dǎo)致用戶不能實時播發(fā)一些地點的內(nèi)容。當(dāng)然，實際應(yīng)用時具體采用哪種傳輸方式可根據(jù)需要確定，且流式傳輸也支持在播放前完全下載到硬盤。③.二者比較 （a）從視頻質(zhì)量上講，實時流式傳輸必須匹配連接帶寬，由于出錯丟失的信息被忽略掉，網(wǎng)絡(luò)擁擠或出現(xiàn)問題時，視頻質(zhì)量會很差；如欲保證視頻質(zhì)量，順序流式傳輸更好。 （b）實時流式傳輸需要特定服務(wù)器，如QuickTime Streaming Server、Real Server與Windows Media Server，這些服務(wù)器允許對媒體發(fā)送進(jìn)行更多級別的控制，因而系統(tǒng)設(shè)置、管理比標(biāo)準(zhǔn)HTTP服務(wù)器更復(fù)雜。 （c）實時流式傳輸還需要特殊網(wǎng)絡(luò)協(xié)議，如：RTSP (Realtime Streaming Protocol)，這些協(xié)議在有防火墻時有時會出現(xiàn)問題，導(dǎo)致用戶不能看到一些地點的實時內(nèi)容；而順序流與傳輸與防火墻無關(guān)。（4）、流媒體播放方式①.單播即客戶端與媒體服務(wù)器間建立單獨傳輸通道，某服務(wù)器傳輸?shù)臄?shù)據(jù)包只能發(fā)送到一個客戶端的傳輸方式。采用該方式時，客戶端須單獨向媒體服務(wù)器發(fā)送查詢信息,媒體服務(wù)器同樣須向各終端發(fā)送所申請數(shù)據(jù)包的拷貝。這種巨大冗余既造成沉重的服務(wù)器負(fù)擔(dān)，又導(dǎo)致所需響應(yīng)時間較長、甚至可能停播，特別是管理方需配置相應(yīng)硬件和帶寬才能保證一定的服務(wù)質(zhì)量。②.組播即利用IP組播技術(shù)構(gòu)建具有組播能力的網(wǎng)絡(luò)，允許路由器一次將數(shù)據(jù)包拷到多個通道的播放方式。采用該方式，各媒體服務(wù)器只需要發(fā)送一個數(shù)據(jù)、而不是多個，就能同時對若干客戶端發(fā)送連續(xù)數(shù)據(jù)流而無延時，所有發(fā)出請求的客戶端共享同一信息包，并且信息可發(fā)送任意地址客戶端，從而顯著減少網(wǎng)絡(luò)傳輸數(shù)據(jù)量。這樣，網(wǎng)絡(luò)利用率顯著提高，成本明顯下降。③.點播與廣播。前者是客戶端與服務(wù)器間的主動連接方式，用戶通過選擇內(nèi)容項目來初始化客戶端連接，可選擇開始、停止、后退、快進(jìn)、暫停流等，該連接方式實現(xiàn)對流的最大控制，但由于各客戶端獨立連接服務(wù)器，因而網(wǎng)絡(luò)帶寬難以保證；后者指用戶被動接收流的連接方式，該方式中數(shù)據(jù)包將發(fā)送給網(wǎng)絡(luò)上的所有用戶，客戶端只能接收但不能控制流，例如，用戶端不能暫停、快進(jìn)、后退數(shù)據(jù)流等。上述幾種播放方式中，單播方式需復(fù)制多個數(shù)據(jù)包，并以多個點對點的方式分別傳輸給所需用戶；廣播方式的數(shù)據(jù)包則傳輸給網(wǎng)絡(luò)上的所有用戶，不管其是否需要，這兩種傳輸方式顯然非常浪費網(wǎng)絡(luò)帶寬。而組播方式取上述兩種方式之長處，克服其弱點，僅將數(shù)據(jù)包傳輸給需要的那些客戶。由于該方式不需傳輸大量數(shù)據(jù)包，亦不將數(shù)據(jù)包發(fā)送給并非需要用戶，有效保證媒體傳輸僅占用最小帶寬。（5）、流媒體系統(tǒng)的關(guān)鍵技術(shù) 　　流媒體系統(tǒng)中，影響流媒體播放質(zhì)量的3個最關(guān)鍵的因素是：編碼和壓縮的性能與效率、媒體服務(wù)器的性能、媒體流傳輸?shù)馁|(zhì)量控制。 ①.編碼/壓縮技術(shù)　　流媒體系統(tǒng)中的編碼用于創(chuàng)建、捕捉和編輯多媒體數(shù)據(jù)，形成流媒體格式。 　　 影響音/視頻流的編碼性能的因素很多：首先是編碼效率，要求在保證一定音/視頻質(zhì)量的前提下，媒體流的碼流速率盡量低，以達(dá)到壓縮流媒體文件的目的。其次是編碼的冗余性和可靠性，與普通多媒體文件壓縮/編碼不同的是，流媒體文件需要在網(wǎng)絡(luò)上實時傳輸，因此必須考慮傳輸中數(shù)據(jù)丟失對解碼質(zhì)量的影響。在Internet環(huán)境下，最典型的方法是多描述編碼(MDC)。MDC把原始的視頻序列壓縮成多位流，每個流對應(yīng)一種描述，都可以提供可接受的視覺質(zhì)量，多個描述結(jié)合起來提供更好的質(zhì)量。最后需要考慮速率調(diào)節(jié)的能力，一種方法是采用可擴(kuò)展的層次編碼，生成多個子位流（Substream），其中一個位流是基本位流，它可以獨立解碼，輸出粗糙質(zhì)量的視頻序列，其他的子位流則起質(zhì)量增強(qiáng)的作用，所有的子位流一起還原出最好質(zhì)量的視頻序列。當(dāng)網(wǎng)絡(luò)速率變化時，可以通過調(diào)節(jié)流輸出的層次來控制碼流的速率，從而適應(yīng)網(wǎng)絡(luò)速率的變化。 ②.媒體服務(wù)器 　　流媒體系統(tǒng)中的媒體服務(wù)器用于存放和控制流媒體的數(shù)據(jù)?！　‰S著流媒體規(guī)模的擴(kuò)大，流媒體服務(wù)器的性能成為制約流媒體服務(wù)擴(kuò)展能力的重要因素。流媒體服務(wù)器性能的關(guān)鍵指標(biāo)是流輸出能力和能同時支持的并發(fā)請求數(shù)量。影響流媒體服務(wù)器性能的因素很多，包括CPU能力、I/O總線、存儲帶寬等。通常單個流媒體服務(wù)器的并發(fā)數(shù)都在幾百以內(nèi)，因此為了具有更好的性能，目前的高性能流媒體服務(wù)器都采用大規(guī)模并行處理的結(jié)構(gòu)，例如采用超立方體的結(jié)構(gòu)將各個流媒體服務(wù)單元連接起來。還有一種方法是采用簡單的PC集群的方式，這種方式下多個PC流媒體服務(wù)器用局域網(wǎng)連接，前端采用內(nèi)容交換/負(fù)載均衡器將流媒體服務(wù)的請求分布到各個PC媒體服務(wù)單元。后一種方式的性能不如前一種方式，但是成本低，容易實現(xiàn)。③.流媒體傳輸網(wǎng)絡(luò)　　流媒體傳輸網(wǎng)絡(luò)是適合多媒體傳輸協(xié)議甚至是實時傳輸協(xié)議的網(wǎng)絡(luò)。（6）、流媒體相關(guān)協(xié)議流媒體在網(wǎng)絡(luò)上的傳輸必然涉及到網(wǎng)絡(luò)傳輸協(xié)議，這是制約流媒體性能的最重要的因素。為了保證對網(wǎng)絡(luò)擁塞、時延和抖動極其敏感的流媒體業(yè)務(wù)在面向無連接的IP網(wǎng)絡(luò)中的服務(wù)質(zhì)量，必須采用合適的協(xié)議，其中包括Internet的多媒體傳輸協(xié)議，以及一些實時流式傳輸協(xié)議等。由于TCP協(xié)議開銷較多，不適合傳輸實時數(shù)據(jù)。一般采用HTTP/TCP傳輸控制信息、用RTP/UDP來傳輸實時信息，實現(xiàn)流式傳輸。具體介紹如下：①.實時傳輸協(xié)議RTP實時傳輸協(xié)議RTP（RealTimeTransportProtocol）與實時傳輸控制協(xié)議RTCP（RealTimeTransportControlProtocol）。前者是一種用于網(wǎng)絡(luò)上針對多媒體數(shù)據(jù)流的傳輸協(xié)議，適合一對一、一對多傳輸情況，目的是提供時間信息并實現(xiàn)流同步。它不作為獨立網(wǎng)絡(luò)層實現(xiàn)，而是應(yīng)用程序一部分，使用UDP來傳輸數(shù)據(jù)，但也可在TCP、ATM等協(xié)議上工作；后者能為按順序傳輸?shù)臄?shù)據(jù)包提供可靠傳輸機(jī)制，并和RTP一起提供流量控制、擁塞控制服務(wù)。RTP會話期間，各客戶端周期性傳輸RTCP包。該包中含有已傳輸?shù)臄?shù)據(jù)包數(shù)量、丟失的數(shù)據(jù)包數(shù)量等信息，服務(wù)器可根據(jù)此信息動態(tài)改變傳輸速率，甚至改變有效載荷類型。上述二者配合使用，能以有效的反饋和最小的開銷實現(xiàn)傳輸效率最佳化，特別適合實時數(shù)據(jù)傳輸。②.實時傳輸控制協(xié)議RTCP 實時傳輸控制協(xié)議RTCP和RTP一起提供流量控制和擁塞控制服務(wù)；在RTP會話期間，各參與者周期性地傳送RTCP包；RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。 RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。③. 實時流協(xié)議RTSP實時流協(xié)議RTSP（RealTimeStreamingProtocol）。Realnetworks和Netscape共同提出的RTSP協(xié)議定義了一對多應(yīng)用程序如何有效通過IP網(wǎng)絡(luò)傳輸多媒體數(shù)據(jù)。其體系結(jié)構(gòu)位于RTP和RTCP之上，使用TCP或RTP完成數(shù)據(jù)傳輸。與請求由客戶端發(fā)出、服務(wù)器作出響應(yīng)的單向方式HTTP相比，RTSP是雙向的，使用時客戶端和服務(wù)器均可發(fā)出請求，且提供操縱播放、快進(jìn)、快倒、暫停及錄制等命令的方法。④.資源預(yù)訂協(xié)議RSVP資源預(yù)訂協(xié)議RSVP（RresourceReserveProtocol）。由于音頻、視頻數(shù)據(jù)流比傳統(tǒng)數(shù)據(jù)對網(wǎng)絡(luò)的延時更敏感，要通過網(wǎng)絡(luò)傳輸高質(zhì)量音頻、視頻信息，除帶寬要求外，還包括其他方面。RSVP作為網(wǎng)絡(luò)資源預(yù)訂協(xié)議，通過預(yù)留部分網(wǎng)絡(luò)資源方式，能在一定程度上為流媒體的傳輸提供良好的服務(wù)質(zhì)量QOS。（7）、流媒體技術(shù)在數(shù)字化視頻管理系統(tǒng)的應(yīng)用網(wǎng)絡(luò)的迅猛發(fā)展和普及為流媒體業(yè)務(wù)發(fā)展提供了強(qiáng)大動力，流媒體技術(shù)已廣泛用于數(shù)字監(jiān)控、視頻點播、新聞發(fā)布、電子商務(wù)、視頻會議等，其應(yīng)用將為網(wǎng)絡(luò)信息交流帶來革命性變化。這里主要介紹流媒體技術(shù)在數(shù)字化視頻管理系統(tǒng)中的應(yīng)用。在數(shù)字化視頻管理系統(tǒng)以數(shù)字視頻處理技術(shù)為核心，結(jié)合網(wǎng)絡(luò)技術(shù)、多媒體技術(shù)，徹底克服模擬監(jiān)控缺點。系統(tǒng)由視頻采集、視頻傳輸、控制中心等組成，對圖像實時性、傳輸速度、并行處理能力、存儲容量等要求較高，并支持多種有線、無線傳輸介質(zhì)，集視頻切換、智能控制、遠(yuǎn)程傳輸、布防報警等功能于一身。其信號傳輸具有以下特點：實時性，即視頻信號須實時處理，如實時壓縮、解壓縮、傳輸；同步性，即視頻信號具有分布性，但用戶終端顯示時須同步；分布性，即現(xiàn)場采集的圖像傳輸、接收、顯示的主機(jī)位于不同地點，通過網(wǎng)絡(luò)相連。視頻傳輸依賴的通信網(wǎng)絡(luò)包括LAN、WAN、ISDN、DDN、ATM、PSTN等，由于每種網(wǎng)絡(luò)傳輸控制及通信協(xié)議均不同，適合遠(yuǎn)程監(jiān)控的數(shù)字視頻傳輸要求標(biāo)準(zhǔn)也不同。目前，TCP/IP協(xié)議作為事實上的標(biāo)準(zhǔn)，廣泛用于各種網(wǎng)絡(luò)。要通過網(wǎng)絡(luò)傳輸數(shù)字視頻，自然也須遵守該協(xié)議。但該協(xié)議最初是為非實時數(shù)據(jù)業(yè)務(wù)制定的，實時傳輸能力較差。而流媒體技術(shù)應(yīng)用于在數(shù)字化視頻管理系統(tǒng)能有效克服其他傳輸方式存在的局限性。其顯著優(yōu)點主要表現(xiàn)為：流媒體實現(xiàn)低帶寬環(huán)境提供高質(zhì)量音頻、視頻等；智能流技術(shù)可保證不同連接速率下的用戶得到相應(yīng)質(zhì)量的媒體播放效果；流媒體多址廣播技術(shù)可顯著減少服務(wù)器負(fù)荷，同時最大限度節(jié)約帶寬。顯然，無論從技術(shù)還是市場角度考慮，流媒體技術(shù)應(yīng)用于遠(yuǎn)程數(shù)字監(jiān)控都有其他方式無可比擬的優(yōu)越性。特別對窄帶遠(yuǎn)程監(jiān)控尤為顯著，用戶不必等遠(yuǎn)端監(jiān)控信息傳輸完畢即可實時、連續(xù)播放，有效克服其它方式播放的等待問題，且實時性較好。當(dāng)然，該方式可能影響視頻圖像質(zhì)量，但考慮到視頻監(jiān)控這種特殊場合無需很高的音視頻質(zhì)量，且服務(wù)器端的記錄已完全滿足詳細(xì)分析、查詢、取證之