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

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