目前，基于TCP/IP的數(shù)據(jù)傳輸網(wǎng)絡(luò)在本質(zhì)上是盡力而為的網(wǎng)絡(luò)，是為傳統(tǒng)數(shù)據(jù)業(yè)務(wù)提供傳輸服務(wù)的網(wǎng)絡(luò)，其傳輸帶寬的波動(dòng)是不可避免的，傳輸延時(shí)也是隨機(jī)的。因此，如何在IP網(wǎng)絡(luò)上提供流媒體服務(wù)并實(shí)時(shí)傳輸視頻，在這里也需要詳細(xì)解讀一下。
一、實(shí)時(shí)視頻網(wǎng)絡(luò)傳輸系統(tǒng)的組成及原理
一個(gè)完整的實(shí)時(shí)視頻網(wǎng)絡(luò)傳輸系統(tǒng)由視頻采集、視頻編碼、傳輸控制協(xié)議處理、1P通信網(wǎng)絡(luò)、視頻解碼等組成。
整個(gè)視頻流的處理、傳輸流程是：在視頻發(fā)送端，對(duì)模擬視頻進(jìn)行采樣，獲得數(shù)字視頻并進(jìn)行視頻編碼，生成適應(yīng)于網(wǎng)絡(luò)傳輸?shù)拿嫦蚓W(wǎng)絡(luò)通信的視頻碼流；根據(jù)反饋信息，估計(jì)網(wǎng)絡(luò)的可用傳輸帶寬，自適應(yīng)地調(diào)整編碼器的編碼輸出速率（包括信源碼率的調(diào)整與信道碼率的調(diào)整），使得視頻碼流能夠滿足當(dāng)前網(wǎng)絡(luò)傳輸可用帶寬的限制；在接收端，對(duì)接收的視頻流進(jìn)行解碼、重構(gòu)視頻信號(hào)、計(jì)算當(dāng)前網(wǎng)絡(luò)傳輸參數(shù)（如傳輸中的丟包率等）并發(fā)送反饋控制信息。
視頻采集部分主要由視頻A/D、視頻D/A、同步邏輯控制、視頻處理、數(shù)據(jù)存儲(chǔ)器構(gòu)成。A/D部分是將各種標(biāo)準(zhǔn)的模擬視頻信號(hào)轉(zhuǎn)換成數(shù)字視頻信號(hào)，作為視頻處理子單元的輸入數(shù)據(jù)；邏輯產(chǎn)生單元通常選用FPGA或CPLD來(lái)完成各種同步邏輯控制，保證采集的實(shí)時(shí)性；對(duì)視頻數(shù)據(jù)進(jìn)行分析和處理，所需運(yùn)算量常常較大，為了保證視頻處理的實(shí)時(shí)性，常采用視頻處理專用芯片、高速DSP、FPGA和DSP等來(lái)完成視頻處理。
視頻編碼部分將數(shù)字視頻信號(hào)壓縮為滿足一定視覺(jué)質(zhì)量要求并且符合一定標(biāo)準(zhǔn)的數(shù)據(jù)流。在視頻流的網(wǎng)絡(luò)通信應(yīng)用中，特別強(qiáng)調(diào)編碼器所生成的視頻流應(yīng)該對(duì)網(wǎng)絡(luò)傳輸帶寬的隨機(jī)波動(dòng)具有自適應(yīng)性。目前常采用可伸縮的視頻編碼器對(duì)視頻信號(hào)進(jìn)行編碼，可伸縮的視頻編碼可以在時(shí)域、空域或正交變換域進(jìn)行，其基本思想是將碼流分成基本層和增強(qiáng)層。其中基本層碼流是必須傳輸?shù)?，包括提供質(zhì)量等級(jí)保證的視頻碼率和視頻序列的運(yùn)動(dòng)矢量：增加層是可選擇傳輸?shù)?，并且可以根?jù)網(wǎng)絡(luò)的傳輸條件進(jìn)行任意截?cái)唷?/span>
傳輸控制部分根據(jù)網(wǎng)絡(luò)的反饋信息，調(diào)整編碼器的編碼速率（信源碼率調(diào)整）和信道差錯(cuò)控制（信道碼率調(diào)整），并使信源碼率與信道碼率達(dá)到分配。為了降低信道突發(fā)誤碼對(duì)視頻碼流的影響，常對(duì)視頻數(shù)據(jù)包進(jìn)行交織處理，以降低臨近數(shù)據(jù)包同時(shí)發(fā)生誤碼的概率，便于接收端的錯(cuò)誤隱藏和恢復(fù)。
在視頻流的網(wǎng)絡(luò)傳輸中，丟包是不可避免的（特別是在無(wú)線網(wǎng)絡(luò)傳輸環(huán)境中）。為了保證完全正確的數(shù)據(jù)包傳輸，可以采用重傳的策略，但對(duì)于視頻流應(yīng)用，因?yàn)閷?duì)時(shí)延的敏感更勝于對(duì)丟包的敏感，所以在接收端，不需要強(qiáng)調(diào)完全正確的數(shù)據(jù)包傳在正確接收的數(shù)據(jù)包基礎(chǔ)上如何提供滿意程度的視頻質(zhì)量則為接收端解碼模塊的中心問(wèn)題。該問(wèn)題等價(jià)于如何利用接收數(shù)據(jù)包的冗余信息，提供更為滿意的解碼視頻流輸出。解決的辦法就是在接收端的錯(cuò)誤隱藏和誤差恢復(fù)。錯(cuò)誤隱藏的方法有：
（1）基于空間相關(guān)性的錯(cuò)誤隱藏。利用錯(cuò)誤塊在同一幀內(nèi)相鄰塊的正確數(shù)據(jù)進(jìn)行內(nèi)插來(lái)重構(gòu)錯(cuò)誤塊的數(shù)據(jù)，以此來(lái)達(dá)到錯(cuò)誤隱藏的目的。這樣才能夠?qū)ο嗨苹蛘吆芏嗉?xì)節(jié)的區(qū)域進(jìn)行很有效的恢復(fù)。
（2）基于時(shí)間相關(guān)性的錯(cuò)誤隱藏。這種方法是利用時(shí)間上相鄰的幀具有很強(qiáng)的相關(guān)性來(lái)進(jìn)行錯(cuò)誤隱藏。錯(cuò)誤隱藏的一個(gè)新的發(fā)展是采用自適應(yīng)的方法進(jìn)行改進(jìn)，即根據(jù)圖像的特點(diǎn)和誤碼的類型來(lái)選擇相應(yīng)的恢復(fù)方法或者是這幾種方法的結(jié)合。自適應(yīng)的一種準(zhǔn)則是恢復(fù)圖像的峰值信噪比（PSNR）化，結(jié)合的方式有線性加權(quán)合并、信噪比合并等。
二、TCP/IP協(xié)議不適合網(wǎng)絡(luò)實(shí)時(shí)傳輸視音頻數(shù)據(jù)
視頻流傳輸與傳統(tǒng)的TCP/IP網(wǎng)絡(luò)的數(shù)據(jù)傳輸有明顯的區(qū)別，主要表現(xiàn)在：傳統(tǒng)的數(shù)據(jù)傳輸對(duì)傳輸延時(shí)和傳輸抖動(dòng)沒(méi)有嚴(yán)格的要求，但是有嚴(yán)格的差錯(cuò)控制和錯(cuò)誤重傳機(jī)制。而視頻流要求傳輸具有實(shí)時(shí)性，對(duì)同步要求較高，并且對(duì)傳輸延時(shí)和抖動(dòng)非常敏感，但在一定的情況下可以允許分組丟失，即可以接受一定程度的傳輸誤碼，并且流媒體服務(wù)具有根據(jù)網(wǎng)絡(luò)的實(shí)時(shí)用傳輸帶寬自適應(yīng)地調(diào)整視頻的傳輸質(zhì)量的能力。
IP網(wǎng)已被廣泛使用在各種場(chǎng)合，其中TCP/IP協(xié)議是各種網(wǎng)絡(luò)操作系統(tǒng)互連和通信的工業(yè)標(biāo)準(zhǔn)。TCP/IP協(xié)議初是為提供非實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)而設(shè)計(jì)的，IP協(xié)議負(fù)責(zé)主機(jī)之間的數(shù)據(jù)傳輸，不進(jìn)行檢錯(cuò)和糾錯(cuò)，因此經(jīng)常發(fā)生數(shù)據(jù)丟失或失序現(xiàn)象。為保證數(shù)據(jù)的可靠傳輸，人們將TCP協(xié)議用于IP數(shù)據(jù)的傳輸，以提高接收端的檢錯(cuò)和糾錯(cuò)能力。當(dāng)檢測(cè)到數(shù)據(jù)包丟失或錯(cuò)誤時(shí)，就會(huì)要求發(fā)送端重新發(fā)送，這樣一來(lái)就不可避免地引起了傳輸延時(shí)和耗用網(wǎng)絡(luò)的帶寬，因此傳統(tǒng)的TCP/IP協(xié)議傳輸實(shí)時(shí)音頻、視頻數(shù)據(jù)的能力較差。當(dāng)然在傳輸用于回放的視頻和音頻數(shù)據(jù)時(shí)，TCP協(xié)議也是一種選擇。如果有足夠大的緩沖區(qū)、充足的網(wǎng)絡(luò)帶寬，在TCP協(xié)議上，接近實(shí)時(shí)的視/音頻傳輸也是可能的。然而，如果在丟包率較高、網(wǎng)絡(luò)狀況不好的情況下，利用TCP協(xié)議進(jìn)行視/音頻通信幾乎是不可能的。TCP和其他傳輸層協(xié)議如XTP不適合實(shí)時(shí)視音頻傳輸?shù)脑蛑饕校?/span>
（1）TCP的重傳機(jī)制不宜。在TCP/IP協(xié)議中，當(dāng)發(fā)送方發(fā)現(xiàn)數(shù)據(jù)丟失時(shí)，它將要求重傳丟失的數(shù)據(jù)包。然而這將需要一個(gè)甚至更多的周期（TCP/IP的快速重傳機(jī)制，將需要3個(gè)額外的幀延遲），這對(duì)于實(shí)時(shí)性要求較高的視/音頻數(shù)據(jù)通信幾乎是災(zāi)難性的，因?yàn)榻邮辗讲坏貌坏却貍鲾?shù)據(jù)的到來(lái)，從而造成了延遲和斷點(diǎn)（音頻的不連續(xù)或視頻的凝固等）。
（2）TCP的擁塞控制機(jī)制不宜。它在探測(cè)到有數(shù)據(jù)包丟失時(shí)，就會(huì)減小它的擁塞窗口。而視/音頻在特定的編碼方式下，產(chǎn)生的編碼數(shù)量（即碼率）是不可能突然改變的。正確的擁塞控制應(yīng)該是變換視/音頻信息的編碼方式，調(diào)節(jié)視頻信息的幀頻或圖像幅面的大小等。
（3）TCP的報(bào)文頭較大。TCP的報(bào)文頭比UDP的報(bào)文頭大，TCP的報(bào)文頭為40B，而UDP的報(bào)文頭僅為12B，并且這些可靠的傳輸層協(xié)議不能提供時(shí)間戳（TimeStamp）和編/解碼信息，而這些信息恰恰是接收方（即客戶端）的應(yīng)用程序所需要的。
（4）啟動(dòng)速度慢。因?yàn)榧幢闶窃诰W(wǎng)絡(luò)運(yùn)行狀態(tài)良好、沒(méi)有丟包的情況下，由于TCP的啟動(dòng)需要建立連接，因而在初始化的過(guò)程中，需要較長(zhǎng)的時(shí)間。顯然，在一個(gè)實(shí)時(shí)視/音頻傳輸應(yīng)用中，盡量少的延遲是我們所期望的。
因此，TCP不適合于視/音頻信息的實(shí)時(shí)傳輸。雖然，TCP/IP協(xié)議可拓寬其應(yīng)用范圍。但單純的TCP/IP協(xié)議已經(jīng)很難適應(yīng)視/音頻通信，特別是連續(xù)的媒體流（如視頻流）通信的要求。TCP協(xié)議是面向連接的協(xié)議，被用于各種網(wǎng)絡(luò)上提供有序可靠數(shù)據(jù)傳輸?shù)奶撾娐贩?wù)，它的重傳機(jī)制和擁塞控制機(jī)制（Congestion Control Mechanism）都是不適合用來(lái)傳輸實(shí)時(shí)視/音頻數(shù)據(jù)的。
三、RTP/RTCP協(xié)議適合實(shí)時(shí)傳輸視音頻
若要在Internet上面提供流媒體數(shù)據(jù)服務(wù)，則需要使用RTP/RTCP（Real-time Transport Protocol/Real-time Transport Control Protocol）協(xié)議。RTP協(xié)議在一對(duì)一或者一對(duì)多的傳輸情況下工作，提供數(shù)據(jù)包傳輸過(guò)程中的時(shí)間信息和實(shí)現(xiàn)流數(shù)據(jù)同步；RTCP協(xié)議與RTP協(xié)議…起工作，提供網(wǎng)絡(luò)傳輸中的流量控制和擁塞控制。RTP/RTCP是一種應(yīng)用型的傳輸層協(xié)議，它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制，它是由IETF（Internet Engineering Task Force）為視/音頻的實(shí)時(shí)傳輸而設(shè)計(jì)的傳輸協(xié)議。RTP協(xié)議位于UDP協(xié)議之上，在功能上獨(dú)立于下面的傳輸層（UDP）和網(wǎng)絡(luò)層，但不能單獨(dú)作為一個(gè)層次存在，通常是利用低層的UDP協(xié)議對(duì)實(shí)時(shí)視/音頻數(shù)據(jù)進(jìn)行組播（Multicast）或單播（Unicast），從而實(shí)現(xiàn)多點(diǎn)或單點(diǎn)視/音頻數(shù)據(jù)的傳輸。
UDP是一種無(wú)連接的數(shù)據(jù)報(bào)投遞服務(wù)，雖然沒(méi)有TCP那么可靠，并且無(wú)法保證實(shí)時(shí)視/音頻傳輸業(yè)務(wù)的服務(wù)質(zhì)量（QoS），需要RTCP實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸和服務(wù)質(zhì)量。但是，由于UDP的傳輸延時(shí)低于TCP，能與視/音頻流很好地匹配。因此，在實(shí)際應(yīng)用中，RTP/RTCP/UDP用于視/音頻媒體，而TCP用于數(shù)據(jù)和控制信令的傳輸。
RTP協(xié)議沒(méi)有連接的概念，它既可以建立在面向連接的底層協(xié)議上，也可以建立在面向無(wú)連接的底層協(xié)議上，因此RTP協(xié)議對(duì)傳輸層是獨(dú)立的。RTP協(xié)議一般由兩個(gè)部分組成：數(shù)據(jù)報(bào)文部分（RTP報(bào)文）和控制報(bào)文部分（RTCP）。RTCP是RTP的控制協(xié)議，它用于監(jiān)視服務(wù)質(zhì)量和正在進(jìn)行的與會(huì)者會(huì)話上傳遞信息，單獨(dú)運(yùn)行在底層協(xié)議上。根據(jù)協(xié)議規(guī)定，RTP和RTCP選用不同的網(wǎng)絡(luò)端口號(hào)，RTP選擇一個(gè)偶數(shù)位的端口號(hào)，而RTCP則選用下一個(gè)奇數(shù)位的端口號(hào)。RTCP是由接收方向發(fā)送的報(bào)文，它負(fù)責(zé)監(jiān)視網(wǎng)絡(luò)的服務(wù)質(zhì)量、通信帶寬，以及網(wǎng)上傳送的信息，并將這些信息發(fā)送給發(fā)送端。RTCP包周期性地向同一個(gè)組播網(wǎng)內(nèi)的所有成員發(fā)送。
RTCP的基本做法是周期性地向會(huì)話的所有參加者進(jìn)行通信，采用和數(shù)據(jù)包分配傳送的相同機(jī)制來(lái)發(fā)送控制包。和RTP協(xié)議相同，RTCP協(xié)議也要求下層協(xié)議提供復(fù)用手段（如要UDP提供不同的端口號(hào)來(lái)實(shí)現(xiàn)復(fù)用）。RTCP的主要功能如下。
（1）數(shù)據(jù)傳輸?shù)馁|(zhì)量提供反饋，并提供QoS的檢測(cè)。所有的接收方把它近的接收情況報(bào)告給所有發(fā)送者，這些信息包括所接收到數(shù)據(jù)包的順序號(hào)、丟失的包數(shù)、亂序包的數(shù)量，以及用于估計(jì)傳輸時(shí)延的時(shí)間戳的信息。而這些信息反映了當(dāng)前的網(wǎng)絡(luò)狀況，發(fā)送方在接收到這些信息后自動(dòng)地調(diào)整它們的發(fā)送速率。
（2）提供不同媒體間的同步。在視/音頻傳輸服務(wù)中，RTP源可能會(huì)有幾種媒體（如視/音頻）需要傳輸，這些不同的媒體之間的同步需要依靠RTCP中包含的時(shí)鐘信息和相關(guān)的RTP時(shí)間戳信息來(lái)進(jìn)行同步。
（3）在會(huì)話的用戶界面上顯示會(huì)話參與者的標(biāo)識(shí)。RTP報(bào)文中提供了SSRC字段來(lái)進(jìn)行源標(biāo)識(shí)，然而，進(jìn)一步的會(huì)話參與者的描述是需要的。RTCP報(bào)文中的源描述（SEDS）提供了會(huì)話參與者的詳盡描述，包括姓名、住址、E-mail等，主要是為會(huì)議電視提供更體貼的支持。當(dāng)然，對(duì)于多視頻服務(wù)器的組播模式也提供了很好的解決方案。
視頻流和音頻流在時(shí)間軸上的連續(xù)性，要求網(wǎng)絡(luò)的實(shí)時(shí)傳輸及高帶寬，同時(shí)又允許傳輸中存在一定的數(shù)據(jù)錯(cuò)誤率及數(shù)據(jù)丟失率。由于RTP本身并不具有一種獨(dú)立傳輸能力，它必須與低層網(wǎng)絡(luò)協(xié)議結(jié)合才能完成數(shù)據(jù)的傳輸服務(wù)。又由于視/音頻在時(shí)間軸上的相關(guān)性不強(qiáng)，而數(shù)據(jù)的實(shí)時(shí)性要高于其可靠性，所以在UDP之上利用RTP/RTCP協(xié)議對(duì)媒體（視頻和音頻）流進(jìn)行封裝、打包和同步，可以使數(shù)字視/音頻信號(hào)的網(wǎng)絡(luò)傳輸延時(shí)達(dá)到小。
由上分析可知，與TCP協(xié)議相比較，RTP協(xié)議提供了一種更適合于實(shí)時(shí)視/音頻信息的傳輸機(jī)制。
