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