EasyDarwin開源社區流媒體視頻課程:流媒體傳輸控制通訊協定(RTSP RTP SDP)詳解之RTP

來源:互聯網
上載者:User

標籤:

視頻課程及相關文檔代碼地址:https://github.com/EasyDarwin/Course#course-3

RTP協議

        即時傳輸協議RTP(Real-time Transport Protocol)是一個網路傳輸協議,它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的,後在RFC3550中進行更新。

         國際電信聯盟ITU-T也發布了自己的RTP文檔,作為H.225.0,但是後來當IETF發布了關於它的穩定的標準RFC後就被取消了。它作為網際網路標準在 [ RFC 3550 ] 有詳細說明.

        RTP協議詳細說明了在互連網上傳遞音頻和視頻的標準資料包格式。它一開始被設計為一個多播協議,但後來被用在很多單播應用中。RTP協議常用於流媒體系統(配合RTSP協議),視頻會議和一鍵通(Push toTalk)系統(配合H.323或SIP),使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一起使用,而且它是建立在使用者資料包通訊協定上的(UDP)。

RTP標準定義了兩個子協議 ,RTP和RTCP

資料轉送協議RTP,用於即時傳輸資料。該協議提供的資訊包括:時間戳記(用於同步)、序號(用於丟包和重排序檢測)、以及負載格式(用於說明資料的編碼格式)。

控制協議RTCP,用於QoS反饋和同步媒體流。相對於RTP來說,RTCP所佔的頻寬非常小,通常只有5%。

為什麼要使用RTP

        一提到流媒體傳輸、一談到什麼視頻監控、視頻會議、語音電話(VOIP),都離不開RTP協議的應用,但當大家都根據經驗或者別人的應用而選擇RTP協議的時候,你可曾想過,為什麼我們要使用RTP來進行流媒體的傳輸呢?為什麼我們一定要用RTP?難道TCP、UDP或者其他的網路通訊協定不能達到我們的要求嗎?

        像TCP這樣的可靠傳輸協議,通過逾時和重傳機制來保證傳輸資料流中的每一個bit的正確性,但這樣會使得無論從協議的實現還是傳輸的過程都變得非常的複雜。而且,當傳輸過程中有資料丟失的時候,由於對資料丟失的檢測(逾時檢測)和重傳,會資料流的傳輸被迫暫停和延時。

        或許你會說,我們可以利用用戶端構造一個足夠大的緩衝區來保證顯示的正常,這種方法對於從網路播放音視頻來說是可以接受的,但是對於一些需要即時互動的場合(如視訊交談、視頻會議等),如果這種緩衝超過了200ms,將會產生難以接受的即時性體驗。

為什麼RTP可以解決上述時延問題

        RTP協議是一種基於UDP的傳輸協議,RTP本身並不能為按順序傳送資料包提供可靠的傳送機制,也不提供流量控制或擁塞控制,它依靠RTCP提供這些服務。這樣,對於那些丟失的資料包,不存在由於逾時檢測而帶來的延時,同時,對於那些丟棄的包,也可以由上層根據其重要性來選擇性的重傳。比如,對於I幀、P幀、B幀資料,由於其重要性依次降低,故在網路狀況不好的情況下,可以考慮在B幀丟失甚至P幀丟失的情況下不進行重傳,這樣,在用戶端方面,雖然可能會有短暫的不清晰畫面,但卻保證了即時性的體驗和要求。

RTP的協議層次 傳輸層的子層

圖 1給出了流媒體應用中的一個典型的協議體繫結構。

        可以看出,RTP被劃分在傳輸層,它建立在UDP上。同UDP協議一樣,為了實現其即時傳輸功能,RTP也有固定的封裝形式。RTP用來為端到端的即時傳輸提供時間資訊和流同步,但並不保證服務品質。服務品質由RTCP來提供。

RTP的工作機製為:

        當應用程式建立一個RTP會話時,應用程式將確定一對目的傳輸地址。目的傳輸地址由一個網路地址和一對連接埠組成,有兩個連接埠:一個給RTP包,一個給RTCP包,使得RTP/RTCP資料能夠正確發送。RTP資料發向偶數的UDP連接埠,而對應的控制訊號RTCP資料發向相鄰的奇數UDP連接埠(偶數的UDP連接埠+1),這樣就構成一個UDP連接埠對。 RTP的發送過程如下,接收過程則相反。

   1) RTP協議從上層接收流媒體資訊碼流(如H.263),封裝成RTP資料包;RTCP從上層接收控制資訊,封裝成RTCP控制包。   2) RTP將RTP 資料包發往UDP連接埠對中偶數連接埠;RTCP將RTCP控制包發往UDP連接埠對中的奇數連接埠。

         RTP分組只包含RTP資料,而控制是由RTCP協議提供。RTP在1025到65535之間選擇一個未使用的偶數UDP連接埠號碼,而在同一次會話中的RTCP則使用下一個奇數UDP連接埠號碼。連接埠號碼5004和5005分別用作RTP和RTCP的預設連接埠號碼。RTP分組的首部格式2所示,其中前12個位元組是必須的。

應用程式層的一部分

        從應用開發人員的角度看,RTP 應當是應用程式層的一部分。在應用的發送端,開發人員必須編寫用 RTP 封裝分組的程式碼,然後把 RTP 分組交給 UDP 插口介面。在接收端,RTP 分組通過 UDP 插口介面進入應用程式層後,還要利用開發人員編寫的程式碼從 RTP 分組中把應用資料區塊提取出來。

RTP包頭中的流媒體特性

首先,我們看看RTP的包頭。
RTP報文頭格式(見RFC3550 Page12):

版本號碼(V):2位元,用來標誌使用的RTP版本。

填充位(P):1位元,如果該位置位,則該RTP包的尾部就包含附加的填充位元組。

擴充位(X): 1位元,如果該位置位的話,RTP固定頭部後面就跟有一個擴充頭部。

CSRC計數器(CC):4位元,含有固定頭部後面跟著的CSRC的數目。

標記位(M): 1位元,該位的解釋由配置文檔(Profile)來承擔.

載荷類型(PayloadType): 7位元,標識了RTP載荷的類型。

序號(SN):16位元,每發送一個 RTP 資料包,序號增加1。接收端可以據此檢測丟包和重建包序列。

時間戳記(Timestamp): 2位元,記錄了該包中資料的第一個位元組的採樣時刻。在一次會話開始時,時間戳記初始化成一個初始值。即使在沒有訊號發送時,時間戳記的數值也要隨時間而不斷地增加(時間在流逝嘛)。時鐘頻率依賴於負載資料格式,並在描述檔案(profile)中進行描述。

同步源標識符(SSRC):32位元,同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標識符是隨機選取的 RFC1889推薦了MD5隨機演算法。

貢獻源列表(CSRC List):0~15項,每項32位元,用來標誌對一個RTP混合器產生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的SSRC標識符插入表中。SSRC標識符都被列出來,以便接收端能正確指出交談雙方的身份。

RTP擴充頭結構

           圖 4 Rtp擴充頭

        若 RTP 固定頭中的擴充位元位置1(注意:如果有CSRC列表,則在CSRC列表之後),則一個長度可變的頭擴充部分被加到 RTP 固定頭之後。頭擴充包含 16 位元的長度域,指示擴充項中 32 位元字的個數,不包括 4 個位元組擴充頭(因此零是有效值)。

        RTP 固定頭之後只允許有一個頭擴充。為允許多個互操作實現獨立產生不同的頭擴充,或某種特定實現有多種不同的頭擴充,擴充項的前 16 位元用以識別標識符或參數。這 16 位元的格式由具體實現的上層協議定義。基本的 RTP 說明並不定義任何頭擴充本身。

RTP的會話過程

        當應用程式建立一個RTP會話時,應用程式將確定一對目的傳輸地址。目的傳輸地址由一個網路地址和一對連接埠組成,有兩個連接埠:一個給RTP包,一個給RTCP包,使得RTP/RTCP資料能夠正確發送。RTP資料發向偶數的UDP連接埠,而對應的控制訊號RTCP資料發向相鄰的奇數UDP連接埠(偶數的UDP連接埠+1),這樣就構成一個UDP連接埠對。

RTP的發送過程如下,接收過程則相反。

  1. RTP協議從上層接收流媒體資訊碼流(如H.263),封裝成RTP資料包;RTCP從上層接收控制資訊,封裝成RTCP控制包。
  2. RTP將RTP 資料包發往UDP連接埠對中偶數連接埠;RTCP將RTCP控制包發往UDP連接埠對中的接收埠。
RTP的profile機制

        RTP為具體的應用提供了非常大的靈活性,它將傳輸協議與具體的應用環境、具體的控制策略分開,傳輸協議本身只提供完成即時傳輸的機制,開發人員可以根據不同的應用環境,自主選擇合適的配置環境、以及合適的控制策略。

        這裡所說的控制策略指的是你可以根據自己特定的應用需求,來實現特定的一些RTCP控制演算法,比如前面提到的丟包的檢測演算法、丟包的重傳策略、一些視頻會議應用中的控制方案等等(這些策略我可能將在後續的文章中進行描述)。

        對於上面說的合適的配置環境,主要是指RTP的相關配置和負載格式的定義。RTP協議為了廣泛地支援各種多媒體格式(如 H.264, MPEG-4, MJPEG, MPEG),沒有在協議中體現出具體的應用配置,而是通過profile設定檔以及負載類型格式說明檔案的形式來提供。對於任何一種特定的應用,RTP定義了一個profile檔案以及相關的負載格式說明,相關的檔案如下所示:

《RTP Profile for Audio and Video Conferences with Minimal Control》(RFC3551)

《RTP Payload Format for H.264 Video》(RFC3984)

《RTP Payload Format for MPEG-4 Audio/Visual Streams》(RFC3016)

等等,想瞭解更多可以點擊這裡:http://en.wikipedia.org/wiki/RTP_audio_video_profile

說明:如果應用程式不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳記,而是使用標準的RTP協議,應用程式就更容易與其他的網路應用程式配合運行,這是大家都希望的事情。例如,如果有兩個不同的公司都在開發網際網路電話軟體,他們都把RTP合并到他們的產品中,這樣就有希望:使用不同公司電話軟體的使用者之間能夠進行通訊。

RTCP的封裝

RTCP的主要功能:
        服務品質的監視與反饋、媒體間的同步,以及多播組中成員的標識。在RTP會話期 間,各參與者周期性地傳送RTCP包。RTCP包中含有已發送的資料包的數量、丟失的資料包的數量等統計資料,因此,各參與者可以利用這些資訊動態地改變傳輸速率,甚至改變有效載荷類型。RTP和RTCP配合使用,它們能以有效反饋和最小的開銷使傳輸效率最佳化,因而特別適合傳送網上的即時資料。

        RTCP也是用UDP來傳送的,但RTCP封裝的僅僅是一些控制資訊,因而分組很短,所以可以將多個RTCP分組封裝在一個UDP包中。RTCP有如下五種分組類型。

類型 縮寫表示 用途
200 SR(Sender Report) 發送端報告
201 RR(Receiver Report) 接收端報告
202 SDES(Source Description Items) 源點描述
203 BYE 結束傳輸
204 . APP 特定應用

上述五種分組的封裝大同小異,下面只講述SR類型,而其它類型請參考RFC3550。

        發送端報告分組SR(Sender Report)用來使發送端以多播方式向所有接收端報告發送情況。SR分組的主要內容有:相應的RTP流的SSRC,RTP流中最新產生的RTP分組的時間戳記和NTP,RTP流包含的分組數,RTP流包含的位元組數。SR包的封裝3所示。

版本(V):同RTP包頭域。

填充(P):同RTP包頭域。

接收報告計數器(RC):5位元,該SR包中的接收報告塊的數目,可以為零。
包類型(PT):8位元,SR包是200。

長度域(Length):16位元,其中存放的是該SR包以32位元為單位的總長度減一。

同步源(SSRC):SR包寄件者的同步源標識符。與對應RTP包中的SSRC一樣。
NTP Timestamp(Network time protocol)SR包發送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。

RTP Timestamp:與NTP時間戳記對應,與RTP資料包中的RTP時間戳記具有相同的單位和隨機初始值。

Sender’s packet count:從開始發送包到產生這個SR包這段時間裡,寄件者發送的RTP資料包的總數. SSRC改變時,這個域清零。

Sender`s octet count:從開始發送包到產生這個SR包這段時間裡,寄件者發送的淨荷資料的總位元組數(不包括頭部和填充)。寄件者改變其SSRC時,這個域要清零。

同步源n的SSRC標識符:該報告塊中包含的是從該源接收到的包的統計資訊。

丟失率(Fraction Lost):表明從上一個SR或RR包發出以來從同步源n(SSRC_n)來的RTP資料包的丟失率。

累計的包丟失數目:從開始接收到SSRC_n的包到發送SR,從SSRC_n傳過來的RTP資料包的丟失總數。

收到的擴充最大序號:從SSRC_n收到的RTP資料包中最大的序號,

接收抖動(Interarrival jitter):RTP資料包接受時間的統計方差估計
上次SR時間戳記(Last SR,LSR):取最近從SSRC_n收到的SR包中的NTP時間戳記的中間32位元。如果目前還沒收到SR包,則該域清零。

上次SR以來的延時(Delay since last SR,DLSR):上次從SSRC_n收到SR包到發送本報告的延時。

附: 代碼描述 RTP header :
/* * RTP header */typedef struct {#if 0   //BIG_ENDIA    unsigned int version:2;   /* protocol version */    unsigned int p:1;         /* padding flag */    unsigned int x:1;         /* header extension flag */    unsigned int cc:4;        /* CSRC count */    unsigned int m:1;         /* marker bit */    unsigned int pt:7;        /* payload type */    unsigned int seq:16;      /* sequence number */#else    unsigned int cc:4;        /* CSRC count */    unsigned int x:1;         /* header extension flag */    unsigned int p:1;         /* padding flag */    unsigned int version:2;   /* protocol version */    unsigned int pt:7;        /* payload type */    unsigned int m:1;         /* marker bit */    unsigned int seq:16;      /* sequence number */#endif    u_int32 ts;               /* timestamp */    u_int32 ssrc;             /* synchronization source */    u_int32 csrc[1];          /* optional CSRC list */} rtp_hdr_t;
RTCP Common header :
/* * RTCP common header word */typedef struct {#if 0   //BIG_ENDIA    unsigned int version:2;   /* protocol version */    unsigned int p:1;         /* padding flag */    unsigned int count:5;     /* varies by packet type */#else    unsigned int count:5;     /* varies by packet type */    unsigned int p:1;         /* padding flag */    unsigned int version:2;   /* protocol version */#endif    unsigned int pt:8;        /* RTCP packet type */    unsigned short length;           /* pkt len in words, w/o this word */} rtcp_common_t;
擷取更多資訊

郵件:[email protected]

WEB:www.EasyDarwin.org

Copyright ? EasyDarwin.org 2012-2016

EasyDarwin開源社區流媒體視頻課程:流媒體傳輸控制通訊協定(RTSP RTP SDP)詳解之RTP

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.