MPEG和RTP的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)分析報告研發(fā)

1、基于MPEG-4和RTP的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)研究文/北京郵電大學(xué)通信網(wǎng)絡(luò)綜合技術(shù)研究所龔猷龍劉勇摘要：隨著計算機(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ī)、網(wǎng)絡(luò)及通信技術(shù)的快速發(fā)展和成熟，視頻監(jiān)控系統(tǒng)從模擬視頻監(jiān)控系統(tǒng)逐 漸轉(zhuǎn)向以數(shù)字化和網(wǎng)絡(luò)化為特色

2、的網(wǎng)絡(luò)數(shù)字視頻監(jiān)控系統(tǒng)。早期的模擬視頻監(jiān)控系統(tǒng)主要應(yīng) 用于閉路電視的監(jiān)控，監(jiān)控的范國僅限于本地網(wǎng)絡(luò)。近十多年來，市場對視頻監(jiān)控業(yè)務(wù)的需 求量越來越大，特別是需求形式越來越廣泛。il算機(jī)系統(tǒng)處理能力的提升，圖像壓縮技術(shù)的 更加完善，以及互聯(lián)網(wǎng)應(yīng)用的蓬勃興起，這些技術(shù)的進(jìn)步為視頻監(jiān)控的發(fā)展提供了保證，給 視頻監(jiān)控系統(tǒng)帶來了巨大商機(jī)。受到市場和技術(shù)的驅(qū)動，視頻監(jiān)控的應(yīng)用領(lǐng)域和應(yīng)用的靈活 性也已經(jīng)遠(yuǎn)遠(yuǎn)超出傳統(tǒng)的安防監(jiān)控所左義的范疇，其應(yīng)用面得到了大大地推廣，逐步滲透到 許多對視頻業(yè)務(wù)有極大需求的新興行業(yè)市場。如銀行監(jiān)控、交通監(jiān)控、醫(yī)療監(jiān)護(hù)、通信機(jī)房 監(jiān)控等系統(tǒng)，給人們的生活和工作帶來了極大的便利。視頻

3、監(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ù)，而且使用價格低廉, 滿足大眾化的需求，其應(yīng)用前景十分廣闊。因此，采用IP組網(wǎng)是視頻監(jiān)控系統(tǒng)朝網(wǎng)絡(luò)化發(fā)展 的趨勢。下文主要介紹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)控端包括若干臺攝像機(jī)、一臺矩陣切換器和一臺MPEG-4編碼器；服務(wù)器端由一個主控中

4、心組成，包括用于業(yè)務(wù)平臺管理和調(diào)度的網(wǎng)絡(luò)服務(wù)器，MPEG-4解碼器和顯示設(shè)備：客戶端包 括一個接入IP網(wǎng)的集線器和各個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所示。9圖2系統(tǒng)數(shù)據(jù)流程圖傳輸兩種數(shù)據(jù)流所采用的協(xié)議是不一樣的?？刂菩畔⒘鲗Ψ?wù)器平臺業(yè)務(wù)管理、客戶端 與視頻端的接入、調(diào)度及解碼顯示等都是十分重要的，可見在控制信息流的傳輸過程中不允 許有丟包，因此采用而向連接、可靠傳輸?shù)腡CP協(xié)議傳輸控制信息。然而TCP傳輸需要的網(wǎng) 絡(luò)開銷較

5、大，通過降低有效性來換取傳輸?shù)目煽啃?，不能達(dá)到實(shí)時傳輸媒體流的目的。UDP 協(xié)議是而向無連接、不可靠傳輸?shù)目刂茀f(xié)議，傳輸之前不需要先建立連接，在傳輸時延及帶 寬利用率方而都要強(qiáng)于TCP,正好滿足了媒體流實(shí)時性的特點(diǎn)，通常采用UDP作為媒體流的 傳輸協(xié)議。不過，采用UDP傳輸媒體流同樣存在不可靠性的問題：UDP數(shù)據(jù)包沒有編號，無 法提供差錯控制，也不保證包不丟失，更不能加載媒體流的時間信息。導(dǎo)致在客戶端顯示的 視頻圖像存在延時和抖動，在一立程度上仍然不能達(dá)到實(shí)時傳輸?shù)男Ч１?給出的是中國 電信有關(guān)IP承載網(wǎng)絡(luò)端到端通信質(zhì)量要求，可供參考。表1網(wǎng)絡(luò)通信質(zhì)量要求 丟包率上限 網(wǎng)絡(luò)延時上限 延時抖動

6、上限1/1000150ms50ms為了彌補(bǔ)UDP協(xié)議存在的缺點(diǎn)，使IP網(wǎng)絡(luò)具有提供媒體流實(shí)時傳輸?shù)哪芰?，IP網(wǎng)絡(luò)視 頻監(jiān)控系統(tǒng)采用由IETF制左的實(shí)時傳輸協(xié)議RTP。RTP由兩個相關(guān)協(xié)議組成：實(shí)時傳輸協(xié)議 RTP和實(shí)時傳輸控制協(xié)議RTCPo視頻壓縮編解碼技術(shù)是視頻監(jiān)控系統(tǒng)的核心技術(shù)。視頻監(jiān)控端采集的原始數(shù)據(jù)量很大， 不適合直接在帶寬受限的網(wǎng)絡(luò)中傳輸，需要先對原始數(shù)據(jù)進(jìn)行壓縮。視頻壓縮標(biāo)準(zhǔn)主要有兩 個系列，一個是由ITU-T制定的H. 26x系列，另一個是由ISO制定的MPEG-x系列。目前比較 看好的國際標(biāo)準(zhǔn)是H. 264和MPEG-4。綜合考慮算法的復(fù)雜度、性能、市場占有率及今后的發(fā) 展等因

7、素，選擇MPEG-4作為視頻監(jiān)控系統(tǒng)的壓縮編碼框架。三、視頻監(jiān)控系統(tǒng)的關(guān)鍵技術(shù)1. MPEG-4壓縮標(biāo)準(zhǔn)MPEG-4標(biāo)準(zhǔn)采用的仍然是以前標(biāo)準(zhǔn)(H. 261/3和MPEG-1/2)的基本編碼框架，即典型的 三步：預(yù)測編碼、變換量化和炳編碼。新的壓縮編碼標(biāo)準(zhǔn)都是基于優(yōu)化的思想進(jìn)行設(shè)計的， 將先前標(biāo)準(zhǔn)中的某些技術(shù)加以改進(jìn)，例如在原來的基礎(chǔ)上提出1/4和1/8像素精度的運(yùn)動補(bǔ) 償技術(shù)，使得預(yù)測編碼的性能大大提高，或加入以前標(biāo)準(zhǔn)中沒有的新技術(shù)。與MPEG-1和MPEG-2 有很大的不同，MPEG-4標(biāo)準(zhǔn)不僅僅給出了具體壓縮算法，它是針對數(shù)字電視、交互式多媒體 應(yīng)用、視頻監(jiān)控等整合及壓縮技術(shù)的需要而制左的

8、。MPEG-4將多種多媒體應(yīng)用集成在一個完 整的框架里，為不同的應(yīng)用提供相應(yīng)地檔次和級別。MPEG-4標(biāo)準(zhǔn)中最大的特點(diǎn)是：采用了基于對象的編碼理念。傳統(tǒng)的視頻編碼方法依照 信源編碼理論的框架，利用輸入信號的隨機(jī)特性達(dá)到壓縮的目的，而并沒有考慮信息獲取者 的主觀意義和主觀特性，還有事件本身的具體含義、重要性及后果等。MPEG-4標(biāo)準(zhǔn)中引用了 視頻對象的概念，打破了過去以宏塊為單位編碼的限制，英目的在于采用現(xiàn)代圖像編碼方法, 利用人眼視覺特性，抓住圖像信息傳輸?shù)谋举|(zhì)，從輪廓、紋理的思路出發(fā)，支持基于視頻內(nèi) 容的交互功能。以上這些都是根據(jù)人眼感興趣的一些特性提出來的。視頻序列中每一幀由不同的場景組成

9、，這些場景可以根據(jù)人的主觀性進(jìn)行劃分，每一個 場景可看成是一個V0P,而同一對象連續(xù)的V0P稱為視頻對象VO。V0可以是視頻序列中的人 物或具體的景物，也可以是訃算機(jī)生成的二維或三維圖形。視頻監(jiān)控系統(tǒng)中，視頻監(jiān)控端主 要采集的是自然景物的圖片，因此這里只考慮MPEG-4中自然視頻序列的編碼檔次。MPEG-4 是以V0P為單位進(jìn)行編解碼，編解碼過程如圖3所示。圖3 MPEG-4編解碼基本過程編碼器包含三個主要部分，形狀編碼、運(yùn)動信息編碼及紋理編碼。(1) ?形狀編碼V0P的形狀信息有兩類：二值形狀信息和灰度形狀信息。二值形狀信息用0, 1來表示V0P 的形狀：灰度形狀信息用0255之間的數(shù)值表示

10、V0P內(nèi)務(wù)像素的透明度。目前的標(biāo)準(zhǔn)中采用 矩陣的形式來表示二值或灰度形狀信息，稱之為位圖(或alpha平而)。實(shí)驗(yàn)表明，位圖表示 法具有較髙的編碼效率和較低的運(yùn)算復(fù)雜度。(2) ?運(yùn)動信息編碼VOP的編碼有三種模式，即幀內(nèi)編碼模式(I-VOP),幀間預(yù)測編碼模式(P-VOP),幀間雙 向預(yù)測編碼模式(B-VOP) o為了適應(yīng)任意形狀的VOP, MPEG-4引入了圖像填充技術(shù)和多邊形匹 配技術(shù)。對于標(biāo)準(zhǔn)宏塊的運(yùn)動估計和補(bǔ)償，可采用傳統(tǒng)的基于塊的方法。而對于VOP邊界的 輪屎宏塊，則要采用圖像填充技術(shù)，再用多邊形匹配技術(shù)進(jìn)行運(yùn)動估計/補(bǔ)償。(3) ?紋理編碼一個視頻平面的紋理信息可以表示為亮度Y和

11、兩個色度成分Cr、Cb。在幀內(nèi)情況下，紋 理信息直接包含亮度和色度成分，在運(yùn)動補(bǔ)償?shù)那闆r下，紋理信息表示經(jīng)過運(yùn)動補(bǔ)償后的殘 差。2. RTP協(xié)議RTP是由IETF音視頻工作組制左的實(shí)時傳輸協(xié)議，$門用于交互式語音、視頻傳輸?shù)?實(shí)時多媒體應(yīng)用。RTP可以在點(diǎn)對點(diǎn)或點(diǎn)對多點(diǎn)的傳輸情況下工作，而且通常使用UDP來傳 送數(shù)據(jù)。當(dāng)應(yīng)用程序開始一個RTP會話時，同時還要開啟RTCP協(xié)議，因?yàn)镽TP協(xié)議并不能提 供差錯控制和保證的網(wǎng)絡(luò)的QoS,需要和RTCP配合使用。此時的會話將使用兩個端口： 一個 給RTP,另一個給RTCP。RTP協(xié)議的設(shè)計目的是提供實(shí)時數(shù)據(jù)傳輸中的時間戳信息及各數(shù)拯流的同步功能。RTP

12、 提供序列號以恢復(fù)數(shù)據(jù)包的順序，實(shí)現(xiàn)丟包檢測，為實(shí)時傳輸提供網(wǎng)絡(luò)擁塞等信息：提供時 間戳用于媒體同步，使接收端按正確的速率回放數(shù)據(jù)：提供同步源標(biāo)志使接收端有可能獲得 有關(guān)發(fā)送方的信息。RTCP的主要功能是提供有關(guān)QoS的信息反饋。網(wǎng)絡(luò)終端系統(tǒng)可根據(jù)這些 反饋信息來調(diào)整數(shù)據(jù)的發(fā)送速率。RTCP包共有五種類型：發(fā)送端報告(SR)、接收端報告(RR)、 源描述(SDES)、BYE和APP。苴中，SR用來描述發(fā)送端的發(fā)送和接收統(tǒng)訃數(shù)據(jù)；RR用來描述 接收端的接收統(tǒng)訃數(shù)據(jù)。這些統(tǒng)汁數(shù)據(jù)包括發(fā)送包數(shù)、發(fā)送字節(jié)數(shù)、累計丟包數(shù)、已收報文 的最大序列號、達(dá)到時間間隔抖動等。實(shí)時傳輸協(xié)議RTP和傳輸控制協(xié)議RTC

13、P 起提供流量 控制和擁塞控制服務(wù)。在RTP會話期間，各參與者周期性地傳輸RTCP包。服務(wù)器利用RTCP 包中所包含的信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。因此，RTP用來傳送實(shí)時 多媒體數(shù)據(jù)信息，而RTCP用來傳送控制信息。四、視頻監(jiān)控系統(tǒng)的視頻流傳輸視頻監(jiān)控端采集的視頻數(shù)據(jù)，先被送入MPEG-4編碼器進(jìn)行壓縮，生成MPEG-4視頻流， 然后將此視頻流打包成RTP數(shù)據(jù)包再傳輸。以下將詳細(xì)分析這個過程。1. RTP打包傳輸視頻流通過RTP打包傳輸，RTP數(shù)據(jù)包由RTP包頭和不立長的連續(xù)媒體數(shù)據(jù)載荷組成。 RTP數(shù)據(jù)包如圖4所示，其中的載荷是MPEG-4視頻流。4 RTP數(shù)據(jù)包格式幾個關(guān)

14、鍵字段的含義前而已給出，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混合器能將從多個終端系統(tǒng)接收到的MPEG-4和其他實(shí)時數(shù)據(jù)流復(fù)合成一系列合 并的碼流；(4) 通過使用RTP轉(zhuǎn)換器實(shí)現(xiàn)數(shù)據(jù)類型的轉(zhuǎn)換。2. MPEG-4視頻流格式視頻監(jiān)控系統(tǒng)中，視頻壓縮編碼采用的是MPEG-4標(biāo)準(zhǔn)。而MPEG

15、-4標(biāo)準(zhǔn)左義了 Profile&Level來適應(yīng)不同的應(yīng)用。Profile泄義了一個碼流可以采用哪些技術(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視頻流是以V0P為單位編碼的特點(diǎn)， 傳輸MPEG-4視頻流時，需要先將視頻流加上包頭信息，進(jìn)行RTP

16、打包封裝。MPEG-4視頻流 的打包要遵循兩個原則：為了提高效率和充分利用MPEG-4的編碼特性，以V0P為單位進(jìn)行打包：考慮IP分組網(wǎng)絡(luò)傳送包長的限制，打包的長度L小于最大傳輸單元(MTU) o基于以上的兩個原則，相應(yīng)給出碼流的分片規(guī)則如下：原則上是：一個V0P包單獨(dú)放入單個RTP包中。但是，一個V0P在一個RTP包中放不下的 情況下，此時要考慮將V0P進(jìn)行分片，分別放入多個RTP包，此時須把V0P頭部信息復(fù)制到 每個RTP包，以去除包間的相關(guān)性，達(dá)到丟包的魯棒性：當(dāng)一個Y0P太小時，此時為了提髙RTP傳輸?shù)挠行?減少包數(shù)和降低開銷)，需要將多個 V0P放入一個RTP包中，這些V0P應(yīng)該按

17、照解碼順序放入RTP中。但是，即使最后一個包中 仍有剩余空間，也不能將另一 V0P中的宏塊放入此包中：同屬于一個V0P的控制信息和數(shù)據(jù)信息必須同時出現(xiàn)在一個RTP包中： 一個V0P頭不能分開放在兩個或兩個以上的RTP包中：當(dāng)將多個視頻包串聯(lián)到一個RTP包中時，V0P頭不應(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ī)則，可以 將包格式簡單的分為幀頭配苣信息和基本流信息。每個V0可對應(yīng)多個視頻對象層(VOL),而 且每個VOL可能

18、屬于多個VOo圖5是MPEG-4視頻流封裝結(jié)構(gòu)。圖5視頻流封裝結(jié)構(gòu)從圖中可以看出，傳輸視頻對象每一層的基本流信息時，都需要將這個基本流的屬性同 時傳輸比如，傳輸V01 Layerl的基本流信息，需要將所屬的視頻序列頭、視頻對象頭和視 頻對象層頭一同傳輸。而且傳輸V01 Layer2的基本流信息時，也需要將這些屬性再次傳輸。 既可以保證基本流信息的完整性，又具有魯棒性。MPEG-4視頻流由若干個視頻對象序列(VS)組成。VS的每一幀可分割為一些任意形狀的 V0,個視頻對象V0又是由同一 V0P的連續(xù)系列構(gòu)成。在具體的實(shí)現(xiàn)中，需用分層的方式組 織各個頭信息。圖6給出了視頻流的分層語法結(jié)構(gòu)。圖6 M

19、PEG-4視頻流分層結(jié)構(gòu)上圖中每個模塊代表一個函數(shù)實(shí)現(xiàn)，模塊的名字取于對應(yīng)函數(shù)的首寫字母組合。對應(yīng)關(guān) 系及功能如下： VS： VisualObjectSequenceO,表示完整的MPEG-4的場景，給岀了檔次和級別信息； VO： VisualObject (),表示一個視頻對象對應(yīng)著場景中的一個特左對象： VOL： VideoObjectLayerO,給出了當(dāng)前視頻流的一些特性： GOP： Group_of_VideoObjectPlane (),提供碼流的隨機(jī)訪問點(diǎn)： VOP： VideoObjectPlaneO,包含了視頻對象的運(yùn)動參數(shù)、形狀信息和紋理信息： MST： Motion_sh

20、ape_texture0 ,給出了運(yùn)動參數(shù)、形狀信息和紋理信息； VPH： Video_packet_header (),視頻包頭信息； DPMST: data_partitioned_motion_shape_texture () 運(yùn)動信息和紋理數(shù)拯分開編碼： CMST: combined_motion_shape_texture ()運(yùn)動信息和紋理數(shù)據(jù)聯(lián)合編碼； MB： Macroblock(),給岀了宏塊數(shù)據(jù)，包括運(yùn)動矢量和紋理信息。從以上的實(shí)現(xiàn)函數(shù)可以看到，在加入一系列頭信息的情況下，整個視頻流是以VOP對單 位封裝傳輸。而每個VOP的編碼都是以宏塊為單位，有關(guān)宏塊級的數(shù)據(jù)流分析就不在

21、加以描 述了。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種，每一檔次可能支持幾種視頻對象和 級別?？梢?，設(shè)計一個視頻監(jiān)控系統(tǒng)，MPEG-4視頻流的封裝過程是十分重要的。五、結(jié)束語在視頻監(jiān)控系統(tǒng)的研究中，MPEG-4視頻流實(shí)時傳輸是網(wǎng)絡(luò)監(jiān)控系統(tǒng)的一個重要課題，也是網(wǎng) 絡(luò)化進(jìn)程中的難題。近年來，網(wǎng)絡(luò)技術(shù)和視頻壓縮編碼技術(shù)取得了極大的進(jìn)步，特別是MPEG-4 標(biāo)準(zhǔn)和RTP網(wǎng)絡(luò)傳輸協(xié)議的提出，很好的解決了這個難題

22、。文中將這兩種關(guān)鍵技術(shù)相結(jié)合， 給岀了一種視頻監(jiān)控系統(tǒng)的碼流傳輸方案。但是，隨著科技的不斷發(fā)展和市場需求的日益增 多，目前的技術(shù)可能會被繼續(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)。請參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)”(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化 程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。版權(quán)聲明Copyright (C)ThelnternetSociety(2001).摘要本文描述了在RTP包中傳輸文本交談內(nèi)容的方法，關(guān)于文

23、本交談會話內(nèi)容在ITU-T建議 (T. 1401)中有詳細(xì)說明。文本交談可以用來單獨(dú)傳輸或與音視頻等交談工具一起構(gòu)成多媒體交談服務(wù)。本RTP負(fù)載包含可選的已傳輸數(shù)據(jù)包的冗余文本來降低包丟失的風(fēng)險。冗余碼參照RFC 2198o目錄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使用冗余時的“靜音期”傳輸54. 范例65. 安全性考慮76. MINEMEDIATYPEREGISTRATIONS 76. lRegistrationo

24、fMIEmediatypetext/tl40 7鳴謝8作者地址8參考8版權(quán)說明9致謝91. 簡介本文左義了一種用于在RTP包中傳輸文本交談會話內(nèi)容的負(fù)載格式，文本交談會話內(nèi)容 在ITU-T建議（T. 1401）中有詳細(xì)說明。文本交談可單獨(dú)傳輸或與音視頻等交談工具共同 構(gòu)成多媒體交談服務(wù)。文本交談中的文本應(yīng)盡快傳輸，或者經(jīng)過一個小的緩沖延遲。 文本的輸入通常是以鍵盤、手寫識別、語音識別或是其它輸入方法。字符的輸入率通常 為每秒幾個字符。這樣，期望的字符傳輸率也較低。通常每個包中只有很少的新字符需要傳 輸。在T. 140中指泄文本和其它T. 140元素必須以經(jīng)過UTF-8變換的IS010646-1

25、碼來傳送。 這些有助于實(shí)現(xiàn)國際化應(yīng)用，并且易于處理現(xiàn)代信息技術(shù)環(huán)境中的文本。本文RTP負(fù)載中 的文本編碼嚴(yán)格遵守T. 140,沒有任何附加幀。通常是UTF-8編碼的IS010616單字符。 T. 140要求字符按照原始順序，沒有重復(fù)的傳輸。文本交談的使用者希望文本傳輸沒有 或盡可能少丟失。當(dāng)然，如果能標(biāo)識出丟失的信息，則丟失的可接受程度會高些。 因此，這里介紹了一個基于RTP的機(jī)制。它將按照原始順序，無重復(fù)傳輸，并且提供 丟失檢測和指示。它同時也提供一個可選方案，利用重復(fù)的冗余數(shù)據(jù)來降低丟失文本風(fēng)險。 考慮到包開銷通常遠(yuǎn)遠(yuǎn)大于T. 140內(nèi)容，傳輸通道中增加冗余數(shù)據(jù)造成的負(fù)擔(dān)很小。1. 1術(shù)語

26、本文中的關(guān)鍵字“必須”，“必須不”，“要求的”，應(yīng)該”，不應(yīng)該”，“會”，“不會”，建議”，“或許”，可選的”在RFC2119E4中解釋。2. RTP用法當(dāng)RTP傳輸中需要傳輸T. 140文本交談，應(yīng)該使用本文所述的負(fù)載。這種負(fù)載格式的文本交談RTP包的格式包括：一個RTP頭（在RFC18892中有上義）， 苴后緊接著是一個T. 140數(shù)據(jù)塊（這里被立義為“T140block”）。該負(fù)載格式?jīng)]有附加頭。T140塊包括中定義的一個或多個T. 140碼元素。大部分T. 140碼元素為IS0106455單 字符，但是也有一些是多字符序列。英中每個字符均為UTF-8編碼6的一個或多個字節(jié)。 這說明不管

27、單個字符中有幾個字節(jié)，每一塊必須包含UTF-8碼的整數(shù)倍。這也說明任何組 合的字符序列（CCS）應(yīng)該被放到同一塊中。T140塊可能會根據(jù)RFC2198E3所泄義的負(fù)載格式傳輸冗余數(shù)據(jù)。這樣，RTP頭后將 是一或多個冗余數(shù)據(jù)塊頭，個數(shù)與從攜帶的冗余T140塊數(shù)相同，最后是此包的新T140塊。2. 1RTP包頭每個RTP包開始于一個固定的RTP頭。下而列出了用于T. 140文本流的幾個RTP頭字 段。負(fù)載類型（PT）： RTP負(fù)載類型的分配是使用該負(fù)載格式的RTP框架特左的。對于利用 動態(tài)負(fù)載類型號的協(xié)議子集，這種負(fù)載格式被命需為T140（參照第六節(jié)）。如果按照RFC 2198使用冗余數(shù)據(jù)，負(fù)載類

28、型中必須指立負(fù)載格式（RED）。順序號：順序號必須嚴(yán)格按照每個新傳送包以一遞增。它用于包丟失和亂序檢測，同時 也可以用于獲取冗余文本，重組文本和標(biāo)記丟失文本。時間戳：RTP時間戳記錄了包中主文本塊采樣時間的近似值。必須使用1000赫茲的時鐘頻率。連續(xù)包不能使用相同的時間戳。由于包不按固泄間隔發(fā)送，所以時間戳不能直接被 用于指示包丟失。2. 2附加頭本負(fù)載格式?jīng)]有定義專門的附加頭。當(dāng)要按RFC2198傳輸冗余數(shù)據(jù)時，RTP頭后緊跟者一個或多個冗余數(shù)據(jù)塊頭，每個冗余數(shù)據(jù)塊都要有一個對應(yīng)的冗余數(shù)據(jù)塊頭。這些頭部均提供了時間戳位移和相應(yīng)的數(shù)據(jù)塊長 度，以及指示了這種負(fù)載格式（T140）的負(fù)載類型號。2

29、. 3T. 140文本結(jié)構(gòu)T. 140文本是按T. 140協(xié)議規(guī)左經(jīng)過UTF-8編碼的，沒有額外組幀。當(dāng)用該格式傳輸冗 余數(shù)據(jù)時，發(fā)送者會選擇每個包中要傳輸?shù)腡140block數(shù)。數(shù)越高則將丟包保護(hù)性越好，但 同時也會增加數(shù)據(jù)傳輸率。由于數(shù)據(jù)包并非按一左的時間間隔產(chǎn)生，如果不提供附加信息，時間戳在包丟失時就無 法標(biāo)識岀該包。冗余數(shù)據(jù)頭并沒有提供順序號，所以必須遵循附加規(guī)則才能將丟失主數(shù)據(jù)所 對應(yīng)的冗余數(shù)據(jù)正確的插入T140blocks主數(shù)據(jù)流中：1. 每個冗余數(shù)據(jù)塊必須與先前傳輸原始數(shù)據(jù)的T140塊數(shù)據(jù)相同，并標(biāo)識為相同的時 間戳位移。2. 冗余數(shù)據(jù)必須按照時間順序放置，最近的冗余T140塊位

30、于冗余區(qū)的最后。3. 必須包括從最早的T140blocks到新數(shù)據(jù)塊前的T140blocks所有的T140塊，。通過這些規(guī)則，冗余T140塊的順序號可以從當(dāng)前RTP頭的序號反向推算得到。結(jié)果就 是負(fù)載中的所有文本都是連續(xù)且順序的。3. 推薦過程這部分描述了負(fù)載格式使用的推薦過程，根據(jù)接受包的信息，接收者可以：1. 把錯亂文本重新排序。2. 標(biāo)識丟失文本。3. 用冗余數(shù)據(jù)補(bǔ)償丟失包。3. 1基本推薦過程只有合法的T. 140格式的數(shù)據(jù)包才被傳輸，T. 140數(shù)據(jù)的排序要使用順序號。在接收端，將RTP順序號與最后一次正確接收包的序號相比較，如果是連續(xù)的，就從 中取出 T140blocko3. 2補(bǔ)

31、償丟包的推薦過程為了減少包丟失時的數(shù)據(jù)丟失，可以根據(jù)RFC2198在包中使用冗余數(shù)據(jù)。如果無法得 知網(wǎng)絡(luò)條件，建議每一包中只使用一個冗余T140塊。如果RTP序號出現(xiàn)空隙，且后續(xù)包中 的冗余T140塊可用，則可以通過包中RTP頭的序號逆向推算出冗余T140塊的序號。如果 該冗余T140塊的序號與丟失的相吻合，就用冗余T140塊來替換丟失T140塊。無論是否使用冗余數(shù)據(jù)，都應(yīng)該在T140塊的接收流中插入一個丟失文本標(biāo)記來標(biāo)志丟 失的數(shù)據(jù)，見ITU-TT. 140附錄。3. 3補(bǔ)償亂序包的推薦過程對于亂序包的檢測，接收端應(yīng)該采取下屬程序。如果接收包序號有空隙，但沒有可用的 冗余數(shù)據(jù)來填充那個空隙，

32、則接收包將被存儲在緩存中來等待丟失包的到達(dá)。建議等待時間 限于0.5秒。如果使用了冗余，并且冗余數(shù)乘以T. 140緩沖時間比0.5秒長，則等待時間應(yīng) 延長到該乘積。如果空隙數(shù)據(jù)包在限制時間內(nèi)到達(dá)，則將它被插入到空隙中，這樣從空隙前沿開始的T140塊就恢復(fù)連續(xù)了。任何沒有在限制時間內(nèi)到達(dá)的T140塊將被視為丟失。3. 4使用冗余時的“靜音期”傳輸當(dāng)使用冗余傳輸模式且T. 140沒有數(shù)據(jù)要傳輸時，最后傳輸?shù)囊粋€T140塊有可能在作 冗余數(shù)據(jù)傳送之前就失效。這樣就不能對文本輸入序列的末尾提供有效的丟包保護(hù)。為了要 避免這種情況，應(yīng)該傳送一個0長度的攜帶冗余數(shù)據(jù)的原始T140塊。根據(jù)2. 3節(jié)，為了能

33、正確推算冗余T140塊的序號，任何被當(dāng)作原始數(shù)據(jù)為0長度的T140 塊必須如同正常文本塊一樣在接下來的包中當(dāng)作冗余傳輸。最后一個T140塊的冗余不應(yīng)該由重復(fù)傳送同一個包（相同序號）來解決，因?yàn)檫@樣會 造成RTCP報告的包丟失數(shù)量減少。4. 范例這是一個沒有冗余的T140RTP包的例子012301234567890123456789012345678901+_+-+-+_+_+-4+_+_+-+-+_+_+-4-+_+_+-+-+_+_44-+_+4-+_+4-+_+V=2 P X|CC=0 M T140PT!順序號丨+_4_+_+_+_4_4+_+_+_+_H+_+_4_l+_+_+_l+_+

34、_+_l+_+ | 時間戳(1000Hz) |+_4+_+_+_4_+_h_+_4_+_+_+_4_l+_+_H+_+_+_+_+_l+_+_+_+_+ 丨同步源(SSRC)標(biāo)識符|+-1+4-1+-+-1+4-1+4-+-+4-1+1+1+T. 140編碼數(shù)據(jù)+II這是一個攜帶冗余數(shù)據(jù)的RTP包的例子012301234567890123456789012345678901+-+4-4-+4-1+-1+-1+4-1+1+1+ v=2 p x cc=o mTredptI 主序號 I+_4_+_+_+_4_4+_+_4_4_+_+_4_l+_+_H+_+_4_l+_+_+_l+_+_+_l+_+

35、I原始數(shù)據(jù)時間戳I+_4+_+_+_4_+_h_+_4_+_+_+_4_l+_+_H+_+_+_+_+_l+_+_+_l+_+ 丨同步源(SSRC)標(biāo)識符|+一+一+一4_1+一+一+一+一+一+一+一+一4_+一+一+一+一+一+一1+一+1 T140PT|R時間戳位移|R塊長度I+_4_+_+_+_4_+_1_+_4_1+_+_4_1+_+_0 T140PTII+RT140編碼冗余數(shù)拯+IIIII+H+4-+_1+4-+4-1+-1+4-1+|PT. 140編碼原始數(shù)據(jù)|+II+-+-+-+-+-+-+-+-+-+-4+-+-+-+-+-+-+-+-+-+-+-+-+-+附圖：RTP文本包

36、的例子5. 安全性考慮既然本負(fù)載格式的目的是在文本交談中攜帶文本，加密的安全性度量就變得十分重要。文本傳輸?shù)臄?shù)量很少，這樣我們可以選擇任何加密方法來對T. 140會話或者整個RTP包進(jìn) 行加密。如果數(shù)據(jù)包中包含了冗余數(shù)據(jù)，要使用同RFC2198 -樣的安全性考慮。6. MINEMediaTypeRegistrations本文檔描述了一種新的RTP負(fù)載需稱和相應(yīng)的MIME類型，T140(text/tl40).6. lRegistrationofMIEmediatypetext/tl40HIMEmediatypename:textMIMEsubtypename:t140必需參數(shù):無可選參數(shù):無編碼

37、考慮:按RFC2793規(guī)定傳輸T140文本。安全性考慮：無互操作考慮:無已發(fā)行規(guī)范:ITU-T建議T. 140, RFC2793.使用該媒體類型的應(yīng)用：文本通信終端和文本會議工具。附加信息:無Magicnumber(s):無文件擴(kuò)展：無Macintosh文件類型碼：無聯(lián)系辦法：GunnarHe1lstrome-mail：gunnar he11stromomnitor se預(yù)期使用:COMMONAuthor/Changecontroller：GunnarHe1lstrom IETFavtWGgunnar hellstromomnitor se c/oSteveCasnercasnerS 鳴謝感謝

38、StephenCasner和Col inPerkins在本文寫作時給予的細(xì)查和建議。 感謝Ericsson公司的MickeyNasiri提供的實(shí)驗(yàn)環(huán)境。感謝MicheleMizarro驗(yàn)證了負(fù)載格式的可用性。作者地址GunnarHe1lstromOmnitorABAlsnogatanT, 4trSE-11641StockholmSwedenPhone:+46708204288/+46855600203Fax:+46855600206EMail：gunnar hellstromomnitor se參考1 ITU-TRecommendationT 140(1998)-Textconversatio

39、nprotocol formultimediaapplication, withamendmentl, (2000).2 Schulzrinne, H,Casner, S,Frederick, R andV Jacobson,Z，RTP: ATransportProtocolforReal-TimeApplicationsz RFC1889, Januaryl996.3 Perkins, C,Kouvelas, I,Hardman, V,Handley, M andJBolot,RTPPayloadforRedundantAudioData, RFC219& Septemberl9974 Br

40、adner, S,KewordsforuseinRFCstoIndicateRequirement Levels, BCP14, RFC2119, Marchl997.51ISO/IEC10646-1:(1993), UniversalMultipleOctetCoded CharacterSet6Yergeau, F,UTF-& atransformationformatofIS010646， RFC 2279, Januaryl998.版權(quán)說明Copyright (C)ThelnternetSociety(2000) AllRightsReservedThisdocumentandtran

41、slationsofitmaybecopiedandfurnishedto others, andderivativeworksthatcommentonorotherwiseexplainit orassistinitsimplementationmaybeprepared, copied, published anddistributed, inwho1eorinpart, withoutrestrictionofany kind, providedthattheabovecopyrightnoticeandthisparagraphare includedonallsuchcopiesa

42、ndderivativeworks However, this documentitselfmaynotbemodifiedinanay, suchasbyremoving thecopyrightnoticeorreferencestothelnternetSocietyorother Internetorganizations,exceptasneededforthepurposeof developinginternetstandardsinwhichcasetheproceduresfor copyrightsdefinedinthelnternetStandardsprocessmu

43、stbe followed, orasrequiredtotranslateitintolanguagesotherthan EnglishThelimitedpermissionsgrantedaboveareperpetualandwillnotbe revokedbythelnternetSocietyoritssuccessorsorassignsThisdocumentandtheinformationcontainedhereinisprovidedonan ASISbasisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING TASKFO

44、RCEDISCLAIMSALLWARRANTIES, EXPRESSORIMPLIED,INCLUDING BUTNOTLIMITEDTOANWARRANTYTHATTHEUSEOFTHEINFORNWTION HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.致謝FundingfortheRFCEditorfunctioniscurrentlyprovidedbythelnternetSociety.實(shí)時傳輸協(xié)議（RTP）為數(shù)據(jù)提供了具有實(shí)時

45、特征的端對端傳送服務(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ù)拯到 多個目的地。RTP本身并沒有提供按時發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這 一過程。RTP并不保證傳送或防止無序傳送，也不確左底層網(wǎng)絡(luò)的可靠性。RTP實(shí)行有序 傳送，RTP中的序列號允許接收方重組發(fā)送方的包序列，同時序列號也能用于決立適當(dāng)?shù)陌?位置，例如：在視頻解碼中，就不需要順

46、序解碼。RTP由兩個緊密鏈接部分組成：* RTP 一傳送具有實(shí)時屬性的數(shù)據(jù)：*RTP控制協(xié)議（RTCP） 一監(jiān)控服務(wù)質(zhì)量并傳送正在進(jìn)行的會話參與者的相關(guān)信息。RTCP第 二方而的功能對于“松散受控”會話是足夠的，也就是說，在沒有明確的成員控制和組織的 情況下，它并不非得用來支持一個應(yīng)用程序的所有控制通信請求。協(xié)議結(jié)構(gòu)1238916bitVPXCSRC CountMPayload TypeSequence numberTimestampSSRCCSRC （variable 0-15 items 32bits each）* V -版本。識別RTP版本。*P 間隙（Padding）。設(shè)宜時，數(shù)據(jù)包包

47、含一個或多個附加間隙位組，其中這部分不屬于 有效載荷。* X 一擴(kuò)展位。設(shè)宜時，在固宦頭后而，根據(jù)指定格式設(shè)置一個擴(kuò)展頭。* CSRC Count -包含CSRC標(biāo)識符（在固定頭后）的編號。* M 一標(biāo)記。標(biāo)記由Profile文件左義。允許重要事件如幀邊界在數(shù)據(jù)包流中進(jìn)行標(biāo)記。* Payload Type 識別RTP有效載荷的格式，并通過應(yīng)用程序決左其解釋。Profile文件 規(guī)左了從Pay load編碼到Payload格式的缺省靜態(tài)映射。另外的Pay load Type編碼可能 通過非RTP方法實(shí)現(xiàn)動態(tài)泄義。* Sequence Number 一每發(fā)送一個RTP數(shù)據(jù)包，序列號增加1。接收方可

48、以依次檢測數(shù)據(jù) 包的丟失并恢復(fù)數(shù)據(jù)包序列。* Timestamp -反映RTP數(shù)據(jù)包中的第一個八位組的采樣時間。采樣時間必須通過時鐘及 時提供線性無變化增雖獲取，以支持同步和抖動計算。*SSRC 同步源。該標(biāo)識符隨機(jī)選擇，旨在確保在同一個RTP會話中不存在兩個同步源具 有相同的SSRC標(biāo)識符。* CSRC 一貢獻(xiàn)源標(biāo)識符。識別該數(shù)據(jù)包中的有效載荷的貢獻(xiàn)源。RTP控制協(xié)議（RTCP）采用與數(shù)據(jù)包相同的分發(fā)機(jī)制，將控制包周期性傳輸?shù)剿袝拝⑴c 者中。底層協(xié)議必須提供數(shù)據(jù)和控制包的多路發(fā)送，例如使用不同的UDP端口號。RTCP主 要完成四個功能服務(wù)：1. RTCP提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息。這是RT

49、P作為傳輸協(xié)議的部分功能并且它涉及到了其 它傳輸協(xié)議的流控制和擁塞控制。2. RTCP為RTP源攜帶一個持久性傳輸層標(biāo)識符，稱為規(guī)范名或CNAME。由于一旦發(fā)現(xiàn)沖 突或程序重啟時，SSRC標(biāo)識符會隨之改變，所以接收方需要CNAME來跟蹤每一個參與者。 同時接收方還要求CNAME能夠與一組相關(guān)RTP會話中來自于給左參與者的多重數(shù)據(jù)流相關(guān) 聯(lián)，例如同步視頻和音頻。3. 上述前兩個功能要求所有的參與者都要發(fā)送RTCP包，因此必須控制速率以便RTP按比 例增加大量的參與者。通過每一個參與者發(fā)送各自的控制包給其它所有參與者，每一個參與 者能夠獨(dú)立觀察到參與者數(shù)量，該數(shù)量可用來計算控制包的發(fā)送速率。4.

50、OPTIONAL功能用于傳送最少會話控制信息，例如在用戶界而顯示參與者標(biāo)識。這對于“松 散受控”會話（在沒有成員控制或闡述協(xié)商的情況下，參與者可以加入或退出該會話）是非 常有用的。上述功能1 一 3適用于所有環(huán)境，尤其是IP組播環(huán)境。RTP應(yīng)用程序設(shè)計者應(yīng)該避免設(shè) 計只能工作于單播模式并且不能增加到大量數(shù)量的機(jī)制。在某些情況下如單向鏈接中，不可 能有來自接收方的反饋，所以RTCP的傳輸就可能由發(fā)送方和接收方分別獨(dú)立控制。協(xié)議結(jié)構(gòu)23816 bitVersionPRCPacket typeLength* Version 一識別RTP版本。RTP數(shù)據(jù)包中的該值與RTCP數(shù)據(jù)包中的一樣。當(dāng)前規(guī)范 能

51、義的版本值為2 o* P -間隙（Padding）。設(shè)巻時，RTCP數(shù)據(jù)包包含一些其它padding八位位組，它們不 屬于控制信息。Padding的最后八位是用于計算應(yīng)該忽略多少間隙八位位組。一些加密算法 中需要計算固泄塊大小時也可能需要使用Padding字段。在一個復(fù)合RTCP數(shù)據(jù)包中，只有 最后的個別數(shù)據(jù)包中才需要使用padding ,這是因?yàn)閺?fù)合數(shù)據(jù)包是作為一個整體來加密的。* RC 一接收方報告計數(shù)。包含在該數(shù)據(jù)包中的接收方報告塊的數(shù)量，有效值為0。* Packet type 一包括常量200 ,識別這是一個RTCP SR數(shù)據(jù)包。* Length 一 RTCP數(shù)據(jù)包的大小（32位字減去

52、1）,包含頭和任意間隙（偏移量的引入使 得0成為有效值，并避免了掃描復(fù)合RTCP數(shù)據(jù)包過程中的無限循環(huán)現(xiàn)象，而采用32位字 計數(shù)方法則避免了對4的倍數(shù)的有效性校驗(yàn)）。RTP/RTCP （實(shí)時傳輸協(xié)議/實(shí)時傳輸控制協(xié)議）基于UDP派生出的協(xié)議，并增加了對實(shí)時傳輸 的控制。一般用于網(wǎng)上傳輸實(shí)時視頻數(shù)據(jù)，比如遠(yuǎn)程視頻監(jiān)控，視頻點(diǎn)播等。有一本名叫多 媒體網(wǎng)絡(luò)傳輸協(xié)議的書上對此2個協(xié)議的結(jié)構(gòu)和原理做了比較詳細(xì)的介紹，好象是淸華大 學(xué)出版社岀版的。?我去年做遠(yuǎn)程視頻監(jiān)控系統(tǒng)時，曾用基于2個協(xié)議，用Wonsock I具封裝了一個網(wǎng)絡(luò)傳 輸動態(tài)連接庫，專門用于局域網(wǎng)組播傳輸實(shí)時視頻數(shù)拯。以下是我針對此2個協(xié)議

53、泄義的相 關(guān)C結(jié)構(gòu)。? /*Current protocol version */define RTP.VERSION? 2Sdefine MIN.SEQUENTIAL? 1Sdefine RTP_SEQ_HOD (116)#define RTP_MAX_SDES 255? /* maximum text length for SDES */define MID_BUFFER_NUM? 2Sdefine NfAX.DROPOUT? 25typedef enum ? RTCP.SR? = 200, ? RTCP_RR? = 201, ? RTCP.SDES 二 202, ? RTCP_BYE?

54、= 203, ? RTCP_APP? = 204 rtcp_type_to typedef enum ? RTCP_SDES_END? = 0, ? RTCP_SDES_CNAME = 1, ? RTCP_SDES_NAME?二 2, ? RTCP_SDES_EMAIL = 3, ? RTCP_SDES_PHOE 二 4, ? RTCP_SDES_LOC? = 5, ? RTCP_SDES_TOOL?二 6, ? RTCP_SDES_NOTE?二 7, ? RTCP_SDES_PRIV?二 8 rt cp_s de s_type_t。/*?* RTP data header?*/ typede

55、f struct 99 unsignedintversion:2o ?/*protocol version*/99 unsignedintp 1八99Q99QP9/*padding flag */99 unsignedint咒1 a 99Q99099/*header extensionflag */99 unsignedintCC：4o ?/*CSRC count */99 unsignedintm：lo ?/*marker bit */99 unsignedintpt:7o ?/*payload type */99 u_intl6 seq9999999999099/*sequence number99 u_int32 1 99999999990099/*timestamp */99 u_int32 ssrc999999990099/*synchronizatio