基于MPEG-4和RTP的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)研究.doc

基于MPEG-4和RTP的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)研究文/北京郵電大學(xué)通信網(wǎng)絡(luò)綜合技術(shù)研究所 龔猷龍 劉勇摘 要：隨著計(jì)算機(jī)、網(wǎng)絡(luò)及多媒體通信技術(shù)的發(fā)展，視頻監(jiān)控在業(yè)界得到了廣泛的應(yīng)用，許多先進(jìn)的技術(shù)被逐漸引入視頻監(jiān)控系統(tǒng)。本文采用了遞進(jìn)的方式，先介紹了IP網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的組成及其關(guān)鍵技術(shù)，接著闡述了MPEG-4視頻流的RTP分組凈荷格式。最后，在視頻流的RTP傳輸中，著重分析了MPEG-4視頻流的封裝格式，并給出相應(yīng)的實(shí)現(xiàn)方法。關(guān)鍵詞：視頻監(jiān)控，MPEG-4，RTP，視頻流封裝一、引言隨著計(jì)算機(jī)、網(wǎng)絡(luò)及通信技術(shù)的快速發(fā)展和成熟，視頻監(jiān)控系統(tǒng)從模擬視頻監(jiān)控系統(tǒng)逐漸轉(zhuǎn)向以數(shù)字化和網(wǎng)絡(luò)化為特色的網(wǎng)絡(luò)數(shù)字視頻監(jiān)控系統(tǒng)。早期的模擬視頻監(jiān)控系統(tǒng)主要應(yīng)用于閉路電視的監(jiān)控，監(jiān)控的范圍僅限于本地網(wǎng)絡(luò)。近十多年來，市場對(duì)視頻監(jiān)控業(yè)務(wù)的需求量越來越大，特別是需求形式越來越廣泛。計(jì)算機(jī)系統(tǒng)處理能力的提升，圖像壓縮技術(shù)的更加完善，以及互聯(lián)網(wǎng)應(yīng)用的蓬勃興起，這些技術(shù)的進(jìn)步為視頻監(jiān)控的發(fā)展提供了保證，給視頻監(jiān)控系統(tǒng)帶來了巨大商機(jī)。受到市場和技術(shù)的驅(qū)動(dòng)，視頻監(jiān)控的應(yīng)用領(lǐng)域和應(yīng)用的靈活性也已經(jīng)遠(yuǎn)遠(yuǎn)超出傳統(tǒng)的安防監(jiān)控所定義的范疇，其應(yīng)用面得到了大大地推廣，逐步滲透到許多對(duì)視頻業(yè)務(wù)有極大需求的新興行業(yè)市場。如銀行監(jiān)控、交通監(jiān)控、醫(yī)療監(jiān)護(hù)、通信機(jī)房監(jiān)控等系統(tǒng)，給人們的生活和工作帶來了極大的便利。視頻監(jiān)控系統(tǒng)既可以采用專線組網(wǎng)，也可用IP方式組網(wǎng)。采用專線組網(wǎng)的視頻監(jiān)控系統(tǒng)具有帶寬充足、圖像質(zhì)量好、易維護(hù)等特點(diǎn)，但是費(fèi)用高。TCP/IP網(wǎng)絡(luò)是面向全球用戶，資源共享是TCP/IP最大的優(yōu)點(diǎn)。TCP/IP是目前最流行采用的互聯(lián)網(wǎng)技術(shù)，而且使用價(jià)格低廉，滿足大眾化的需求，其應(yīng)用前景十分廣闊。因此，采用IP組網(wǎng)是視頻監(jiān)控系統(tǒng)朝網(wǎng)絡(luò)化發(fā)展的趨勢(shì)。下文主要介紹IP網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)的特點(diǎn)及其采用的關(guān)鍵技術(shù)。二、IP網(wǎng)絡(luò)監(jiān)控系統(tǒng)結(jié)構(gòu)IP網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)主要由視頻監(jiān)控端、服務(wù)器端和客戶端組成，如圖1所示。其中視頻監(jiān)控端包括若干臺(tái)攝像機(jī)、一臺(tái)矩陣切換器和一臺(tái)MPEG-4編碼器；服務(wù)器端由一個(gè)主控中心組成，包括用于業(yè)務(wù)平臺(tái)管理和調(diào)度的網(wǎng)絡(luò)服務(wù)器，MPEG-4解碼器和顯示設(shè)備；客戶端包括一個(gè)接入IP網(wǎng)的集線器和各個(gè)PC機(jī)終端。各部分通過以太網(wǎng)相連接。圖1 IP網(wǎng)絡(luò)監(jiān)控系統(tǒng)從網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)可以看出，系統(tǒng)中主要存在兩種數(shù)據(jù)流：視頻監(jiān)控端向客戶端發(fā)送的媒體流和客戶端向視頻監(jiān)控端發(fā)送的控制信息流。系統(tǒng)的數(shù)據(jù)流程如圖2所示。?圖2 系統(tǒng)數(shù)據(jù)流程圖傳輸兩種數(shù)據(jù)流所采用的協(xié)議是不一樣的?？刂菩畔⒘鲗?duì)服務(wù)器平臺(tái)業(yè)務(wù)管理、客戶端與視頻端的接入、調(diào)度及解碼顯示等都是十分重要的，可見在控制信息流的傳輸過程中不允許有丟包，因此采用面向連接、可靠傳輸?shù)腡CP協(xié)議傳輸控制信息。然而TCP傳輸需要的網(wǎng)絡(luò)開銷較大，通過降低有效性來換取傳輸?shù)目煽啃?，不能達(dá)到實(shí)時(shí)傳輸媒體流的目的。UDP協(xié)議是面向無連接、不可靠傳輸?shù)目刂茀f(xié)議，傳輸之前不需要先建立連接，在傳輸時(shí)延及帶寬利用率方面都要強(qiáng)于TCP，正好滿足了媒體流實(shí)時(shí)性的特點(diǎn)，通常采用UDP作為媒體流的傳輸協(xié)議。不過，采用UDP傳輸媒體流同樣存在不可靠性的問題：UDP數(shù)據(jù)包沒有編號(hào)，無法提供差錯(cuò)控制，也不保證包不丟失，更不能加載媒體流的時(shí)間信息。導(dǎo)致在客戶端顯示的視頻圖像存在延時(shí)和抖動(dòng)，在一定程度上仍然不能達(dá)到實(shí)時(shí)傳輸?shù)男Ч１?給出的是中國電信有關(guān)IP承載網(wǎng)絡(luò)端到端通信質(zhì)量要求，可供參考。表1 網(wǎng)絡(luò)通信質(zhì)量要求丟包率上限網(wǎng)絡(luò)延時(shí)上限延時(shí)抖動(dòng)上限1/1000150ms50ms為了彌補(bǔ)UDP協(xié)議存在的缺點(diǎn)，使IP網(wǎng)絡(luò)具有提供媒體流實(shí)時(shí)傳輸?shù)哪芰?，IP網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)采用由IETF制定的實(shí)時(shí)傳輸協(xié)議RTP。RTP由兩個(gè)相關(guān)協(xié)議組成：實(shí)時(shí)傳輸協(xié)議RTP和實(shí)時(shí)傳輸控制協(xié)議RTCP。視頻壓縮編解碼技術(shù)是視頻監(jiān)控系統(tǒng)的核心技術(shù)。視頻監(jiān)控端采集的原始數(shù)據(jù)量很大，不適合直接在帶寬受限的網(wǎng)絡(luò)中傳輸，需要先對(duì)原始數(shù)據(jù)進(jìn)行壓縮。視頻壓縮標(biāo)準(zhǔn)主要有兩個(gè)系列，一個(gè)是由ITU-T制定的H.26x系列，另一個(gè)是由ISO制定的MPEG-x系列。目前比較看好的國際標(biāo)準(zhǔn)是H.264和MPEG-4。綜合考慮算法的復(fù)雜度、性能、市場占有率及今后的發(fā)展等因素，選擇MPEG-4作為視頻監(jiān)控系統(tǒng)的壓縮編碼框架。三、視頻監(jiān)控系統(tǒng)的關(guān)鍵技術(shù)1MPEG-4壓縮標(biāo)準(zhǔn) MPEG-4標(biāo)準(zhǔn)采用的仍然是以前標(biāo)準(zhǔn)(H.261/3和MPEG-1/2)的基本編碼框架，即典型的三步：預(yù)測(cè)編碼、變換量化和熵編碼。新的壓縮編碼標(biāo)準(zhǔn)都是基于優(yōu)化的思想進(jìn)行設(shè)計(jì)的，將先前標(biāo)準(zhǔn)中的某些技術(shù)加以改進(jìn)，例如在原來的基礎(chǔ)上提出1/4和1/8像素精度的運(yùn)動(dòng)補(bǔ)償技術(shù)，使得預(yù)測(cè)編碼的性能大大提高，或加入以前標(biāo)準(zhǔn)中沒有的新技術(shù)。與MPEG-1和MPEG-2有很大的不同，MPEG-4標(biāo)準(zhǔn)不僅僅給出了具體壓縮算法，它是針對(duì)數(shù)字電視、交互式多媒體應(yīng)用、視頻監(jiān)控等整合及壓縮技術(shù)的需要而制定的。MPEG-4將多種多媒體應(yīng)用集成在一個(gè)完整的框架里，為不同的應(yīng)用提供相應(yīng)地檔次和級(jí)別。 MPEG-4標(biāo)準(zhǔn)中最大的特點(diǎn)是：采用了基于對(duì)象的編碼理念。傳統(tǒng)的視頻編碼方法依照信源編碼理論的框架，利用輸入信號(hào)的隨機(jī)特性達(dá)到壓縮的目的，而并沒有考慮信息獲取者的主觀意義和主觀特性，還有事件本身的具體含義、重要性及后果等。MPEG-4標(biāo)準(zhǔn)中引用了視頻對(duì)象的概念，打破了過去以宏塊為單位編碼的限制，其目的在于采用現(xiàn)代圖像編碼方法，利用人眼視覺特性，抓住圖像信息傳輸?shù)谋举|(zhì)，從輪廓、紋理的思路出發(fā)，支持基于視頻內(nèi)容的交互功能。以上這些都是根據(jù)人眼感興趣的一些特性提出來的。 視頻序列中每一幀由不同的場景組成，這些場景可以根據(jù)人的主觀性進(jìn)行劃分，每一個(gè)場景可看成是一個(gè)VOP，而同一對(duì)象連續(xù)的VOP稱為視頻對(duì)象VO。VO可以是視頻序列中的人物或具體的景物，也可以是計(jì)算機(jī)生成的二維或三維圖形。視頻監(jiān)控系統(tǒng)中，視頻監(jiān)控端主要采集的是自然景物的圖片，因此這里只考慮MPEG-4中自然視頻序列的編碼檔次。MPEG-4是以VOP為單位進(jìn)行編解碼，編解碼過程如圖3所示。 圖3 MPEG-4編解碼基本過程 編碼器包含三個(gè)主要部分，形狀編碼、運(yùn)動(dòng)信息編碼及紋理編碼。(1)? 形狀編碼VOP的形狀信息有兩類：二值形狀信息和灰度形狀信息。二值形狀信息用0，1來表示VOP的形狀；灰度形狀信息用0255之間的數(shù)值表示VOP內(nèi)各像素的透明度。目前的標(biāo)準(zhǔn)中采用矩陣的形式來表示二值或灰度形狀信息，稱之為位圖(或alpha平面)。試驗(yàn)表明，位圖表示法具有較高的編碼效率和較低的運(yùn)算復(fù)雜度。(2)? 運(yùn)動(dòng)信息編碼VOP的編碼有三種模式，即幀內(nèi)編碼模式(I-VOP)，幀間預(yù)測(cè)編碼模式(P-VOP)，幀間雙向預(yù)測(cè)編碼模式(B-VOP)。為了適應(yīng)任意形狀的VOP，MPEG-4引入了圖像填充技術(shù)和多邊形匹配技術(shù)。對(duì)于標(biāo)準(zhǔn)宏塊的運(yùn)動(dòng)估計(jì)和補(bǔ)償，可采用傳統(tǒng)的基于塊的方法。而對(duì)于VOP邊界的輪廓宏塊，則要采用圖像填充技術(shù)，再用多邊形匹配技術(shù)進(jìn)行運(yùn)動(dòng)估計(jì)/補(bǔ)償。(3)? 紋理編碼一個(gè)視頻平面的紋理信息可以表示為亮度Y和兩個(gè)色度成分Cr、Cb。在幀內(nèi)情況下，紋理信息直接包含亮度和色度成分，在運(yùn)動(dòng)補(bǔ)償?shù)那闆r下，紋理信息表示經(jīng)過運(yùn)動(dòng)補(bǔ)償后的殘差。2RTP協(xié)議 RTP是由IETF音視頻工作組制定的實(shí)時(shí)傳輸協(xié)議，專門用于交互式語音、視頻傳輸?shù)葘?shí)時(shí)多媒體應(yīng)用。RTP可以在點(diǎn)對(duì)點(diǎn)或點(diǎn)對(duì)多點(diǎn)的傳輸情況下工作，而且通常使用UDP來傳送數(shù)據(jù)。當(dāng)應(yīng)用程序開始一個(gè)RTP會(huì)話時(shí)，同時(shí)還要開啟RTCP協(xié)議，因?yàn)镽TP協(xié)議并不能提供差錯(cuò)控制和保證的網(wǎng)絡(luò)的QoS，需要和RTCP配合使用。此時(shí)的會(huì)話將使用兩個(gè)端口：一個(gè)給RTP，另一個(gè)給RTCP。 RTP協(xié)議的設(shè)計(jì)目的是提供實(shí)時(shí)數(shù)據(jù)傳輸中的時(shí)間戳信息及各數(shù)據(jù)流的同步功能。RTP提供序列號(hào)以恢復(fù)數(shù)據(jù)包的順序，實(shí)現(xiàn)丟包檢測(cè)，為實(shí)時(shí)傳輸提供網(wǎng)絡(luò)擁塞等信息；提供時(shí)間戳用于媒體同步，使接收端按正確的速率回放數(shù)據(jù)；提供同步源標(biāo)志使接收端有可能獲得有關(guān)發(fā)送方的信息。RTCP的主要功能是提供有關(guān)QoS的信息反饋。網(wǎng)絡(luò)終端系統(tǒng)可根據(jù)這些反饋信息來調(diào)整數(shù)據(jù)的發(fā)送速率。RTCP包共有五種類型：發(fā)送端報(bào)告(SR)、接收端報(bào)告(RR)、源描述(SDES)、BYE和APP。其中，SR用來描述發(fā)送端的發(fā)送和接收統(tǒng)計(jì)數(shù)據(jù)；RR用來描述接收端的接收統(tǒng)計(jì)數(shù)據(jù)。這些統(tǒng)計(jì)數(shù)據(jù)包括發(fā)送包數(shù)、發(fā)送字節(jié)數(shù)、累計(jì)丟包數(shù)、已收?qǐng)?bào)文的最大序列號(hào)、達(dá)到時(shí)間間隔抖動(dòng)等。實(shí)時(shí)傳輸協(xié)議RTP和傳輸控制協(xié)議RTCP一起提供流量控制和擁塞控制服務(wù)。在RTP會(huì)話期間，各參與者周期性地傳輸RTCP包。服務(wù)器利用RTCP包中所包含的信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。因此，RTP用來傳送實(shí)時(shí)多媒體數(shù)據(jù)信息，而RTCP用來傳送控制信息。四、視頻監(jiān)控系統(tǒng)的視頻流傳輸視頻監(jiān)控端采集的視頻數(shù)據(jù)，先被送入MPEG-4編碼器進(jìn)行壓縮，生成MPEG-4視頻流，然后將此視頻流打包成RTP數(shù)據(jù)包再傳輸。以下將詳細(xì)分析這個(gè)過程。1RTP打包傳輸視頻流通過RTP打包傳輸，RTP數(shù)據(jù)包由RTP包頭和不定長的連續(xù)媒體數(shù)據(jù)載荷組成。RTP數(shù)據(jù)包如圖4所示，其中的載荷是MPEG-4視頻流。 4 RTP數(shù)據(jù)包格式 幾個(gè)關(guān)鍵字段的含義前面已給出，RTP包頭字段的含義與以前的IP數(shù)據(jù)包頭的類似，這里不再詳細(xì)說明。其中，MPEG-4 Visual stream表示MPEG-4的視頻流，被稱為RTP分組凈荷(payload)。采用RTP協(xié)議發(fā)送MPEG-4碼流的好處：(1)可以將MPEG-4碼流和其他的RTP凈荷相同步；(2)可以通過RTCP監(jiān)視MPEG-4的傳送性能；(3)使用RTP混合器能將從多個(gè)終端系統(tǒng)接收到的MPEG-4和其他實(shí)時(shí)數(shù)據(jù)流復(fù)合成一系列合并的碼流；(4)通過使用RTP轉(zhuǎn)換器實(shí)現(xiàn)數(shù)據(jù)類型的轉(zhuǎn)換。2MPEG-4視頻流格式 視頻監(jiān)控系統(tǒng)中，視頻壓縮編碼采用的是MPEG-4標(biāo)準(zhǔn)。而MPEG-4標(biāo)準(zhǔn)定義了Profile&Level來適應(yīng)不同的應(yīng)用。Profile定義了一個(gè)碼流可以采用哪些技術(shù)，Level則規(guī)定了復(fù)雜度，譬如支持多大的圖像格式和大小，需要的緩存量。先進(jìn)簡單檔次(Advanced Simple Profile)是為了適應(yīng)因特網(wǎng)上流媒體應(yīng)用的需求而新增加的，在簡單檔次的基礎(chǔ)上改善了壓縮性能，而且支持隔行掃描視頻編碼。本文討論的視頻監(jiān)控系統(tǒng)采用的是MPEG-4標(biāo)準(zhǔn)中的先進(jìn)簡單檔次(ASP)。（1）視頻流的分片規(guī)則由于IP網(wǎng)絡(luò)中傳輸?shù)姆纸M大小受限制，加上MPEG-4視頻流是以VOP為單位編碼的特點(diǎn)，傳輸MPEG-4視頻流時(shí)，需要先將視頻流加上包頭信息，進(jìn)行RTP打包封裝。MPEG-4視頻流的打包要遵循兩個(gè)原則： 為了提高效率和充分利用MPEG-4的編碼特性，以VOP為單位進(jìn)行打包； 考慮IP分組網(wǎng)絡(luò)傳送包長的限制，打包的長度L小于最大傳輸單元(MTU)?；谝陨系膬蓚€(gè)原則，相應(yīng)給出碼流的分片規(guī)則如下： 原則上是：一個(gè)VOP包單獨(dú)放入單個(gè)RTP包中。但是，一個(gè)VOP在一個(gè)RTP包中放不下的情況下，此時(shí)要考慮將VOP進(jìn)行分片，分別放入多個(gè)RTP包，此時(shí)須把VOP頭部信息復(fù)制到每個(gè)RTP包，以去除包間的相關(guān)性，達(dá)到丟包的魯棒性； 當(dāng)一個(gè)VOP太小時(shí)，此時(shí)為了提高RTP傳輸?shù)挠行?減少包數(shù)和降低開銷)，需要將多個(gè)VOP放入一個(gè)RTP包中，這些VOP應(yīng)該按照解碼順序放入RTP中。但是，即使最后一個(gè)包中仍有剩余空間，也不能將另一VOP中的宏塊放入此包中； 同屬于一個(gè)VOP的控制信息和數(shù)據(jù)信息必須同時(shí)出現(xiàn)在一個(gè)RTP包中； 一個(gè)VOP頭不能分開放在兩個(gè)或兩個(gè)以上的RTP包中； 當(dāng)將多個(gè)視頻包串聯(lián)到一個(gè)RTP包中時(shí)，VOP頭不應(yīng)放到RTP負(fù)載的中間。（2）視頻流的封裝MPEG-4視頻流是RTP數(shù)據(jù)包中的載荷， 給MPEG-4視頻流打包的目的是為了適應(yīng)網(wǎng)絡(luò)的傳輸，讓解碼端能夠恢復(fù)MPEG-4數(shù)據(jù)流并進(jìn)行回放。依照MPEG-4視頻流的分片規(guī)則，可以將包格式簡單的分為幀頭配置信息和基本流信息。每個(gè)VO可對(duì)應(yīng)多個(gè)視頻對(duì)象層(VOL)，而且每個(gè)VOL可能屬于多個(gè)VO。圖5是MPEG-4視頻流封裝結(jié)構(gòu)。圖5 視頻流封裝結(jié)構(gòu) 從圖中可以看出，傳輸視頻對(duì)象每一層的基本流信息時(shí)，都需要將這個(gè)基本流的屬性同時(shí)傳輸。比如，傳輸VO1 Layer1的基本流信息，需要將所屬的視頻序列頭、視頻對(duì)象頭和視頻對(duì)象層頭一同傳輸。而且傳輸VO1 Layer2的基本流信息時(shí)，也需要將這些屬性再次傳輸。既可以保證基本流信息的完整性，又具有魯棒性。 MPEG-4視頻流由若干個(gè)視頻對(duì)象序列(VS)組成。VS的每一幀可分割為一些任意形狀的VO，一個(gè)視頻對(duì)象VO又是由同一VOP的連續(xù)系列構(gòu)成。在具體的實(shí)現(xiàn)中，需用分層的方式組織各個(gè)頭信息。圖6給出了視頻流的分層語法結(jié)構(gòu)。 圖6 MPEG-4視頻流分層結(jié)構(gòu)上圖中每個(gè)模塊代表一個(gè)函數(shù)實(shí)現(xiàn)，模塊的名字取于對(duì)應(yīng)函數(shù)的首寫字母組合。對(duì)應(yīng)關(guān)系及功能如下： VS：VisualObjectSequence()，表示完整的MPEG-4的場景，給出了檔次和級(jí)別信息； VO：VisualObject()，表示一個(gè)視頻對(duì)象對(duì)應(yīng)著場景中的一個(gè)特定對(duì)象； VOL：VideoObjectLayer()，給出了當(dāng)前視頻流的一些特性； GOP：Group_of_VideoObjectPlane()，提供碼流的隨機(jī)訪問點(diǎn)； VOP：VideoObjectPlane()，包含了視頻對(duì)象的運(yùn)動(dòng)參數(shù)、形狀信息和紋理信息； MST：Motion_shape_texture()，給出了運(yùn)動(dòng)參數(shù)、形狀信息和紋理信息； VPH：Video_packet_header()，視頻包頭信息； DPMST：data_partitioned_motion_shape_texture()，運(yùn)動(dòng)信息和紋理數(shù)據(jù)分開編碼； CMST：combined_motion_shape_texture()，運(yùn)動(dòng)信息和紋理數(shù)據(jù)聯(lián)合編碼； MB：Macroblock()，給出了宏塊數(shù)據(jù)，包括運(yùn)動(dòng)矢量和紋理信息。從以上的實(shí)現(xiàn)函數(shù)可以看到，在加入一系列頭信息的情況下，整個(gè)視頻流是以VOP對(duì)單位封裝傳輸。而每個(gè)VOP的編碼都是以宏塊為單位，有關(guān)宏塊級(jí)的數(shù)據(jù)流分析就不在加以描述了。MPEG-4視頻流出現(xiàn)在RTP數(shù)據(jù)包的載荷部分，RTP數(shù)據(jù)包的結(jié)構(gòu)比較清晰，因此RTP的組包過程比較容易實(shí)現(xiàn)。然而，MPEG-4視頻流的分析過程非常復(fù)雜。MPEG-4視頻標(biāo)準(zhǔn)一共定義了19種編碼檔次，其中用于自然編碼的檔次有15種，每一檔次可能支持幾種視頻對(duì)象和級(jí)別?？梢?，設(shè)計(jì)一個(gè)視頻監(jiān)控系統(tǒng)，MPEG-4視頻流的封裝過程是十分重要的。五、結(jié)束語在視頻監(jiān)控系統(tǒng)的研究中，MPEG-4視頻流實(shí)時(shí)傳輸是網(wǎng)絡(luò)監(jiān)控系統(tǒng)的一個(gè)重要課題，也是網(wǎng)絡(luò)化進(jìn)程中的難題。近年來，網(wǎng)絡(luò)技術(shù)和視頻壓縮編碼技術(shù)取得了極大的進(jìn)步，特別是MPEG-4標(biāo)準(zhǔn)和RTP網(wǎng)絡(luò)傳輸協(xié)議的提出，很好的解決了這個(gè)難題。文中將這兩種關(guān)鍵技術(shù)相結(jié)合，給出了一種視頻監(jiān)控系統(tǒng)的碼流傳輸方案。但是，隨著科技的不斷發(fā)展和市場需求的日益增多，目前的技術(shù)可能會(huì)被繼續(xù)淘汰。因此不能安于現(xiàn)狀，需要在網(wǎng)絡(luò)音視頻傳輸技術(shù)領(lǐng)域開展更多、更深入的研究。本備忘錄的狀態(tài)本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建議以得到改進(jìn)。請(qǐng)參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)”(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。版權(quán)聲明Copyright(C)TheInternetSociety(2001).摘要本文描述了在RTP包中傳輸文本交談內(nèi)容的方法，關(guān)于文本交談會(huì)話內(nèi)容在ITU-T建議（T.1401）中有詳細(xì)說明。文本交談可以用來單獨(dú)傳輸或與音視頻等交談工具一起構(gòu)成多媒體交談服務(wù)。本RTP負(fù)載包含可選的已傳輸數(shù)據(jù)包的冗余文本來降低包丟失的風(fēng)險(xiǎn)。冗余碼參照RFC2198。目錄1簡介 21.1術(shù)語 32.RTP用法 32.1RTP包頭 32.2附加頭 42.3T.140文本結(jié)構(gòu) 43.推薦過程 43.1基本推薦過程 53.2補(bǔ)償丟包的推薦過程 53.3補(bǔ)償亂序包的推薦過程 53.4使用冗余時(shí)的“靜音期”傳輸 54.范例 65安全性考慮 76.MIMEMEDIATYPEREGISTRATIONS 76.1RegistrationofMIMEmediatypetext/t140 7鳴謝 8作者地址 8參考 8版權(quán)說明 9致謝 91簡介本文定義了一種用于在RTP包中傳輸文本交談會(huì)話內(nèi)容的負(fù)載格式，文本交談會(huì)話內(nèi)容在ITU-T建議（T.1401）中有詳細(xì)說明。文本交談可單獨(dú)傳輸或與音視頻等交談工具共同構(gòu)成多媒體交談服務(wù)。文本交談中的文本應(yīng)盡快傳輸，或者經(jīng)過一個(gè)小的緩沖延遲。文本的輸入通常是以鍵盤、手寫識(shí)別、語音識(shí)別或是其它輸入方法。字符的輸入率通常為每秒幾個(gè)字符。這樣，期望的字符傳輸率也較低。通常每個(gè)包中只有很少的新字符需要傳輸。在T.140中指定文本和其它T.140元素必須以經(jīng)過UTF-8變換的ISO10646-1碼來傳送。這些有助于實(shí)現(xiàn)國際化應(yīng)用，并且易于處理現(xiàn)代信息技術(shù)環(huán)境中的文本。本文RTP負(fù)載中的文本編碼嚴(yán)格遵守T.140，沒有任何附加幀。通常是UTF-8編碼的ISO10646單字符。T.140要求字符按照原始順序，沒有重復(fù)的傳輸。文本交談的使用者希望文本傳輸沒有或盡可能少丟失。當(dāng)然，如果能標(biāo)識(shí)出丟失的信息，則丟失的可接受程度會(huì)高些。因此，這里介紹了一個(gè)基于RTP的機(jī)制。它將按照原始順序，無重復(fù)傳輸，并且提供丟失檢測(cè)和指示。它同時(shí)也提供一個(gè)可選方案，利用重復(fù)的冗余數(shù)據(jù)來降低丟失文本風(fēng)險(xiǎn)?？紤]到包開銷通常遠(yuǎn)遠(yuǎn)大于T.140內(nèi)容，傳輸通道中增加冗余數(shù)據(jù)造成的負(fù)擔(dān)很小。1.1術(shù)語本文中的關(guān)鍵字“必須”，“必須不”，“要求的”，“應(yīng)該”，“不應(yīng)該”，“會(huì)”，“不會(huì)”，“建議”，“或許”，“可選的”在RFC21194中解釋。2.RTP用法當(dāng)RTP傳輸中需要傳輸T.140文本交談，應(yīng)該使用本文所述的負(fù)載。這種負(fù)載格式的文本交談RTP包的格式包括：一個(gè)RTP頭（在RFC18892中有定義），其后緊接著是一個(gè)T.140數(shù)據(jù)塊（這里被定義為“T140block”）。該負(fù)載格式?jīng)]有附加頭。T140塊包括1中定義的一個(gè)或多個(gè)T.140碼元素。大部分T.140碼元素為ISO106455單字符，但是也有一些是多字符序列。其中每個(gè)字符均為UTF-8編碼6的一個(gè)或多個(gè)字節(jié)。這說明不管單個(gè)字符中有幾個(gè)字節(jié)，每一塊必須包含UTF-8碼的整數(shù)倍。這也說明任何組合的字符序列（CCS）應(yīng)該被放到同一塊中。T140塊可能會(huì)根據(jù)RFC21983所定義的負(fù)載格式傳輸冗余數(shù)據(jù)。這樣，RTP頭后將是一或多個(gè)冗余數(shù)據(jù)塊頭，個(gè)數(shù)與從攜帶的冗余T140塊數(shù)相同，最后是此包的新T140塊。2.1RTP包頭每個(gè)RTP包開始于一個(gè)固定的RTP頭。下面列出了用于T.140文本流的幾個(gè)RTP頭字段。負(fù)載類型（PT）：RTP負(fù)載類型的分配是使用該負(fù)載格式的RTP框架特定的。對(duì)于利用動(dòng)態(tài)負(fù)載類型號(hào)的協(xié)議子集，這種負(fù)載格式被命名為T140（參照第六節(jié)）。如果按照RFC2198使用冗余數(shù)據(jù)，負(fù)載類型中必須指定負(fù)載格式（RED）。順序號(hào)：順序號(hào)必須嚴(yán)格按照每個(gè)新傳送包以一遞增。它用于包丟失和亂序檢測(cè)，同時(shí)也可以用于獲取冗余文本，重組文本和標(biāo)記丟失文本。時(shí)間戳：RTP時(shí)間戳記錄了包中主文本塊采樣時(shí)間的近似值。必須使用1000赫茲的時(shí)鐘頻率。連續(xù)包不能使用相同的時(shí)間戳。由于包不按固定間隔發(fā)送，所以時(shí)間戳不能直接被用于指示包丟失。2.2附加頭本負(fù)載格式?jīng)]有定義專門的附加頭。當(dāng)要按RFC2198傳輸冗余數(shù)據(jù)時(shí)，RTP頭后緊跟者一個(gè)或多個(gè)冗余數(shù)據(jù)塊頭，每個(gè)冗余數(shù)據(jù)塊都要有一個(gè)對(duì)應(yīng)的冗余數(shù)據(jù)塊頭。這些頭部均提供了時(shí)間戳位移和相應(yīng)的數(shù)據(jù)塊長度，以及指示了這種負(fù)載格式(T140)的負(fù)載類型號(hào)。2.3T.140文本結(jié)構(gòu)T.140文本是按T.140協(xié)議規(guī)定經(jīng)過UTF-8編碼的，沒有額外組幀。當(dāng)用該格式傳輸冗余數(shù)據(jù)時(shí)，發(fā)送者會(huì)選擇每個(gè)包中要傳輸?shù)腡140block數(shù)。數(shù)越高則將丟包保護(hù)性越好，但同時(shí)也會(huì)增加數(shù)據(jù)傳輸率。由于數(shù)據(jù)包并非按一定的時(shí)間間隔產(chǎn)生，如果不提供附加信息，時(shí)間戳在包丟失時(shí)就無法標(biāo)識(shí)出該包。冗余數(shù)據(jù)頭并沒有提供順序號(hào)，所以必須遵循附加規(guī)則才能將丟失主數(shù)據(jù)所對(duì)應(yīng)的冗余數(shù)據(jù)正確的插入T140blocks主數(shù)據(jù)流中：1. 每個(gè)冗余數(shù)據(jù)塊必須與先前傳輸原始數(shù)據(jù)的T140塊數(shù)據(jù)相同，并標(biāo)識(shí)為相同的時(shí)間戳位移。2. 冗余數(shù)據(jù)必須按照時(shí)間順序放置，最近的冗余T140塊位于冗余區(qū)的最后。3. 必須包括從最早的T140blocks到新數(shù)據(jù)塊前的T140blocks所有的T140塊，。通過這些規(guī)則，冗余T140塊的順序號(hào)可以從當(dāng)前RTP頭的序號(hào)反向推算得到。結(jié)果就是負(fù)載中的所有文本都是連續(xù)且順序的。3.推薦過程這部分描述了負(fù)載格式使用的推薦過程，根據(jù)接受包的信息，接收者可以：1. 把錯(cuò)亂文本重新排序。2. 標(biāo)識(shí)丟失文本。3. 用冗余數(shù)據(jù)補(bǔ)償丟失包。3.1基本推薦過程只有合法的T.140格式的數(shù)據(jù)包才被傳輸，T.140數(shù)據(jù)的排序要使用順序號(hào)。在接收端，將RTP順序號(hào)與最后一次正確接收包的序號(hào)相比較，如果是連續(xù)的，就從中取出T140block。3.2補(bǔ)償丟包的推薦過程為了減少包丟失時(shí)的數(shù)據(jù)丟失，可以根據(jù)RFC2198在包中使用冗余數(shù)據(jù)。如果無法得知網(wǎng)絡(luò)條件，建議每一包中只使用一個(gè)冗余T140塊。如果RTP序號(hào)出現(xiàn)空隙，且后續(xù)包中的冗余T140塊可用，則可以通過包中RTP頭的序號(hào)逆向推算出冗余T140塊的序號(hào)。如果該冗余T140塊的序號(hào)與丟失的相吻合，就用冗余T140塊來替換丟失T140塊。無論是否使用冗余數(shù)據(jù)，都應(yīng)該在T140塊的接收流中插入一個(gè)丟失文本標(biāo)記來標(biāo)志丟失的數(shù)據(jù)，見ITU-TT.140附錄。3.3補(bǔ)償亂序包的推薦過程對(duì)于亂序包的檢測(cè)，接收端應(yīng)該采取下屬程序。如果接收包序號(hào)有空隙，但沒有可用的冗余數(shù)據(jù)來填充那個(gè)空隙，則接收包將被存儲(chǔ)在緩存中來等待丟失包的到達(dá)。建議等待時(shí)間限于0.5秒。如果使用了冗余，并且冗余數(shù)乘以T.140緩沖時(shí)間比0.5秒長，則等待時(shí)間應(yīng)延長到該乘積。如果空隙數(shù)據(jù)包在限制時(shí)間內(nèi)到達(dá)，則將它被插入到空隙中，這樣從空隙前沿開始的T140塊就恢復(fù)連續(xù)了。任何沒有在限制時(shí)間內(nèi)到達(dá)的T140塊將被視為丟失。3.4使用冗余時(shí)的“靜音期”傳輸當(dāng)使用冗余傳輸模式且T.140沒有數(shù)據(jù)要傳輸時(shí)，最后傳輸?shù)囊粋€(gè)T140塊有可能在作冗余數(shù)據(jù)傳送之前就失效。這樣就不能對(duì)文本輸入序列的末尾提供有效的丟包保護(hù)。為了要避免這種情況，應(yīng)該傳送一個(gè)0長度的攜帶冗余數(shù)據(jù)的原始T140塊。根據(jù)2.3節(jié)，為了能正確推算冗余T140塊的序號(hào)，任何被當(dāng)作原始數(shù)據(jù)為0長度的T140塊必須如同正常文本塊一樣在接下來的包中當(dāng)作冗余傳輸。最后一個(gè)T140塊的冗余不應(yīng)該由重復(fù)傳送同一個(gè)包（相同序號(hào)）來解決，因?yàn)檫@樣會(huì)造成RTCP報(bào)告的包丟失數(shù)量減少。4.范例這是一個(gè)沒有冗余的T140RTP包的例子012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|CC=0|M|T140PT|順序號(hào)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|時(shí)間戳(1000Hz)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|同步源(SSRC)標(biāo)識(shí)符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+T.140編碼數(shù)據(jù)+|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+這是一個(gè)攜帶冗余數(shù)據(jù)的RTP包的例子012301234567890123456789012345678901+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X|CC=0|M|REDPT|主序號(hào)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|原始數(shù)據(jù)時(shí)間戳|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|同步源(SSRC)標(biāo)識(shí)符|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1|T140PT|R時(shí)間戳位移|R塊長度|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0|T140PT|+-+-+-+-+-+-+-+-+|+RT.140編碼冗余數(shù)據(jù)+|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|PT.140編碼原始數(shù)據(jù)|+-+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+附圖：RTP文本包的例子5安全性考慮既然本負(fù)載格式的目的是在文本交談中攜帶文本，加密的安全性度量就變得十分重要。文本傳輸?shù)臄?shù)量很少，這樣我們可以選擇任何加密方法來對(duì)T.140會(huì)話或者整個(gè)RTP包進(jìn)行加密。如果數(shù)據(jù)包中包含了冗余數(shù)據(jù)，要使用同RFC2198一樣的安全性考慮。6.MIMEMediaTypeRegistrations本文檔描述了一種新的RTP負(fù)載名稱和相應(yīng)的MIME類型，T140(text/t140).6.1RegistrationofMIMEmediatypetext/t140MIMEmediatypename:textMIMEsubtypename:t140必需參數(shù):無可選參數(shù):無編碼考慮:按RFC2793規(guī)定傳輸T140文本。安全性考慮：無互操作考慮:無已發(fā)行規(guī)范:ITU-T建議T.140，RFC2793.使用該媒體類型的應(yīng)用:文本通信終端和文本會(huì)議工具。附加信息:無Magicnumber(s):無文件擴(kuò)展:無Macintosh文件類型碼:無聯(lián)系辦法:GunnarHellstrome-mail:gunnar.hellstromomnitor.se預(yù)期使用:COMMONAuthor/Changecontroller:GunnarHellstrom|IETFavtWGgunnar.hellstromomnitor.se|c/oSteveC鳴謝感謝StephenCasner和ColinPerkins在本文寫作時(shí)給予的細(xì)查和建議。感謝Ericsson公司的MickeyNasiri提供的實(shí)驗(yàn)環(huán)境。感謝MicheleMizarro驗(yàn)證了負(fù)載格式的可用性。作者地址GunnarHellstromOmnitorABAlsnogatan7,4trSE-11641StockholmSwedenPhone:+46708204288/+46855600203Fax:+46855600206EMail:gunnar.hellstromomnitor.se參考1ITU-TRecommendationT.140(1998)-Textconversationprotocolformultimediaapplication,withamendment1,(2000).2Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,RTP:ATransportProtocolforReal-TimeApplications,RFC1889,January1996.3Perkins,C.,Kouvelas,I.,Hardman,V.,Handley,M.andJ.Bolot,RTPPayloadforRedundantAudioData,RFC2198,September1997.4Bradner,S.,KeywordsforuseinRFCstoIndicateRequirementLevels,BCP14,RFC2119,March1997.5ISO/IEC10646-1:(1993),UniversalMultipleOctetCodedCharacterSet.6Yergeau,F.,UTF-8,atransformationformatofISO10646,RFC2279,January1998.版權(quán)說明Copyright(C)TheInternetSociety(2000).AllRightsReserved.Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,andderivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementationmaybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestrictionofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedonallsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodifiedinanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSocietyorotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternetstandardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandardsprocessmustbefollowed,orasrequiredtotranslateitintolanguagesotherthanEnglish.ThelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbytheInternetSocietyoritssuccessorsorassigns.ThisdocumentandtheinformationcontainedhereinisprovidedonanASISbasisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE. 致謝FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.實(shí)時(shí)傳輸協(xié)議（RTP）為數(shù)據(jù)提供了具有實(shí)時(shí)特征的端對(duì)端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)。應(yīng)用程序通常在 UDP 上運(yùn)行 RTP 以便使用其多路結(jié)點(diǎn)和校驗(yàn)服務(wù)；這兩種協(xié)議都提供了傳輸層協(xié)議的功能。但是 RTP 可以與其它適合的底層網(wǎng)絡(luò)或傳輸協(xié)議一起使用。如果底層網(wǎng)絡(luò)提供組播方式，那么 RTP 可以使用該組播表傳輸數(shù)據(jù)到多個(gè)目的地。 RTP 本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網(wǎng)絡(luò)的可靠性。 RTP 實(shí)行有序傳送， RTP 中的序列號(hào)允許接收方重組發(fā)送方的包序列，同時(shí)序列號(hào)也能用于決定適當(dāng)?shù)陌恢?，例如：在視頻解碼中，就不需要順序解碼。 RTP 由兩個(gè)緊密鏈接部分組成： * RTP 傳送具有實(shí)時(shí)屬性的數(shù)據(jù)； * RTP 控制協(xié)議（RTCP） 監(jiān)控服務(wù)質(zhì)量并傳送正在進(jìn)行的會(huì)話參與者的相關(guān)信息。RTCP 第二方面的功能對(duì)于“松散受控”會(huì)話是足夠的，也就是說，在沒有明確的成員控制和組織的情況下，它并不非得用來支持一個(gè)應(yīng)用程序的所有控制通信請(qǐng)求。 協(xié)議結(jié)構(gòu)1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC (variable 0 15 items 32bits each)* V 版本。識(shí)別 RTP 版本。 * P 間隙（Padding）。設(shè)置時(shí)，數(shù)據(jù)包包含一個(gè)或多個(gè)附加間隙位組，其中這部分不屬于有效載荷。 * X 擴(kuò)展位。設(shè)置時(shí)，在固定頭后面，根據(jù)指定格式設(shè)置一個(gè)擴(kuò)展頭。 * CSRC Count 包含 CSRC 標(biāo)識(shí)符（在固定頭后）的編號(hào)。 * M 標(biāo)記。標(biāo)記由 Profile 文件定義。允許重要事件如幀邊界在數(shù)據(jù)包流中進(jìn)行標(biāo)記。 * Payload Type 識(shí)別 RTP 有效載荷的格式，并通過應(yīng)用程序決定其解釋。Profile 文件規(guī)定了從 Payload 編碼到 Payload 格式的缺省靜態(tài)映射。另外的 Payload Type 編碼可能通過非 RTP 方法實(shí)現(xiàn)動(dòng)態(tài)定義。 * Sequence Number 每發(fā)送一個(gè) RTP 數(shù)據(jù)包，序列號(hào)增加1。接收方可以依次檢測(cè)數(shù)據(jù)包的丟失并恢復(fù)數(shù)據(jù)包序列。 * Timestamp 反映 RTP 數(shù)據(jù)包中的第一個(gè)八位組的采樣時(shí)間。采樣時(shí)間必須通過時(shí)鐘及時(shí)提供線性無變化增量獲取，以支持同步和抖動(dòng)計(jì)算。 * SSRC 同步源。該標(biāo)識(shí)符隨機(jī)選擇，旨在確保在同一個(gè) RTP 會(huì)話中不存在兩個(gè)同步源具有相同的 SSRC 標(biāo)識(shí)符。 * CSRC 貢獻(xiàn)源標(biāo)識(shí)符。識(shí)別該數(shù)據(jù)包中的有效載荷的貢獻(xiàn)源。 RTP 控制協(xié)議（RTCP）采用與數(shù)據(jù)包相同的分發(fā)機(jī)制，將控制包周期性傳輸?shù)剿袝?huì)話參與者中。底層協(xié)議必須提供數(shù)據(jù)和控制包的多路發(fā)送，例如使用不同的 UDP 端口號(hào)。 RTCP 主要完成四個(gè)功能服務(wù)： 1. RTCP 提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息。這是 RTP 作為傳輸協(xié)議的部分功能并且它涉及到了其它傳輸協(xié)議的流控制和擁塞控制。 2. RTCP 為 RTP 源攜帶一個(gè)持久性傳輸層標(biāo)識(shí)符，稱為規(guī)范名或 CNAME 。由于一旦發(fā)現(xiàn)沖突或程序重啟時(shí)， SSRC 標(biāo)識(shí)符會(huì)隨之改變，所以接收方需要 CNAME 來跟蹤每一個(gè)參與者。同時(shí)接收方還要求 CNAME 能夠與一組相關(guān) RTP 會(huì)話中來自于給定參與者的多重?cái)?shù)據(jù)流相關(guān)聯(lián)，例如同步視頻和音頻。 3. 上述前兩個(gè)功能要求所有的參與者都要發(fā)送 RTCP 包，因此必須控制速率以便 RTP 按比例增加大量的參與者。通過每一個(gè)參與者發(fā)送各自的控制包給其它所有參與者，每一個(gè)參與者能夠獨(dú)立觀察到參與者數(shù)量，該數(shù)量可用來計(jì)算控制包的發(fā)送速率。 4. OPTIONAL 功能用于傳送最少會(huì)話控制信息，例如在用戶界面顯示參與者標(biāo)識(shí)。這對(duì)于“松散受控”會(huì)話（在沒有成員控制或闡述協(xié)商的情況下，參與者可以加入或退出該會(huì)話）是非常有用的。 上述功能 1 3 適用于所有環(huán)境，尤其是 IP 組播環(huán)境。 RTP 應(yīng)用程序設(shè)計(jì)者應(yīng)該避免設(shè)計(jì)只能工作于單播模式并且不能增加到大量數(shù)量的機(jī)制。在某些情況下如單向鏈接中，不可能有來自接收方的反饋，所以 RTCP 的傳輸就可能由發(fā)送方和接收方分別獨(dú)立控制。協(xié)議結(jié)構(gòu)23816 bitVersion PRCPacket typeLength* Version 識(shí)別 RTP 版本。 RTP 數(shù)據(jù)包中的該值與 RTCP 數(shù)據(jù)包中的一樣。 當(dāng)前規(guī)范定義的版本值為 2 。 * P 間隙（Padding）。設(shè)置時(shí)， RTCP 數(shù)據(jù)包包含一些其它 padding 八位位組，它們不屬于控制信息。 Padding 的最后八位是用于計(jì)算應(yīng)該忽略多少間隙八位位組。一些加密算法中需要計(jì)算固定塊大小時(shí)也可能需要使用 Padding 字段。在一個(gè)復(fù)合 RTCP 數(shù)據(jù)包中，只有最后的個(gè)別數(shù)據(jù)包中才需要使用 padding ，這是因?yàn)閺?fù)合數(shù)據(jù)包是作為一個(gè)整體來加密的。 * RC 接收方報(bào)告計(jì)數(shù)。包含在該數(shù)據(jù)包中的接收方報(bào)告塊的數(shù)量，有效值為 0 。 * Packet type 包括常量 200 ，識(shí)別這是一個(gè) RTCP SR 數(shù)據(jù)包。 * Length RTCP 數(shù)據(jù)包的大?。?2 位字減去 1），包含頭和任意間隙 （偏移量的引入使得 0 成為有效值，并避免了掃描復(fù)合 RTCP 數(shù)據(jù)包過程中的無限循環(huán)現(xiàn)象，而采用 32 位字計(jì)數(shù)方法則避免了對(duì) 4 的倍數(shù)的有效性校驗(yàn)）。RTP/RTCP（實(shí)時(shí)傳輸協(xié)議/實(shí)時(shí)傳輸控制協(xié)議）基于UDP派生出的協(xié)議，并增加了對(duì)實(shí)時(shí)傳輸?shù)目刂?。一般用于網(wǎng)上傳輸實(shí)時(shí)視頻數(shù)據(jù)，比如遠(yuǎn)程視頻監(jiān)控，視頻點(diǎn)播等。有一本名叫多媒體網(wǎng)絡(luò)傳輸協(xié)議的書上對(duì)此2個(gè)協(xié)議的結(jié)構(gòu)和原理做了比較詳細(xì)的介紹，好象是清華大學(xué)出版社出版的。? 我去年做遠(yuǎn)程視頻監(jiān)控系統(tǒng)時(shí)，曾用基于2個(gè)協(xié)議，用Wonsock工具封裝了一個(gè)網(wǎng)絡(luò)傳輸動(dòng)態(tài)連接庫，專門用于局域網(wǎng)組播傳輸實(shí)時(shí)視頻數(shù)據(jù)。以下是我針對(duì)此2個(gè)協(xié)議定義的相關(guān)C結(jié)構(gòu)。? /*Current protocol version. */#define RTP_VERSION? 2#define MIN_SEQUENTIAL? 1#define RTP_SEQ_MOD (116)#define RTP_MAX_SDES 255? /* maximum text length for SDES */#define MID_BUFFER_NUM? 2#define MAX_DROPOUT? 25typedef enum ? RTCP_SR? = 200,? RTCP_RR? = 201,? RTCP_SDES = 202,? RTCP_BYE? = 203,? RTCP_APP? = 204 rtcp_type_t;typedef enum ? RTCP_SDES_END? = 0,? RTCP_SDES_CNAME = 1,? RTCP_SDES_NAME? = 2,? RTCP_SDES_EMAIL = 3,? RTCP_SDES_PHONE = 4,? RTCP_SDES_LOC? = 5,? RTCP_SDES_TOOL? = 6,? RTCP_SDES_NOTE? = 7,? RTCP_SDES_PRIV? = 8 rtcp_sdes_type_t;/*?* RTP data header?*/typedef struct ? unsigned int version:2;? /* protocol version */? unsigned int p:1;? /* padding flag */? unsigned int x:1;?