網絡流媒體協議系列：

網絡流媒體協議之——MPEG-DASH協議簡述

網絡流媒體協議之——HLS概述

網絡流媒體協議之——UDP協議概述

今天來整理一下RTP。

RTP(Real-time Transport Protocol，實時傳輸協議)是用于Internet上針對多媒體數據流的一種傳輸協議，由IETF提出，對應的標準文檔是RFC3550。RTP協議和RTCP(Real-time Transport Control Protocol)一起使用。RTP使用偶數端口號收發數據，相應的RTCP則使用相鄰的下一位奇數端口號。

RTP

RTP傳輸基于IP協議，所以最大傳輸單元(MTU)最大為1500字節，在使用IP／UDP／RTP的協議層次結構的時候，這其中包括至少20字節的IP頭，8字節的UDP頭，以及12字節的RTP頭。這樣，頭信息至少要占用40個字節，那么RTP載荷的最大尺寸為1460字節。以H.264?為例，如果一幀數據大于1460，則需要分片打包，然后到接收端再拆包，組合成一幀數據，進行解碼播放。

RTP的使用場景包括：

(1)???簡單多播音頻會議(SimpleMulticast Audio Conference)

(2)???音頻和視頻會議(Audioand Video Conference)

(3)???混頻器和轉換器(Muxersand Translators)

(4)???分層編碼(LayeredEncoding)

其中，混頻器(Mixer)是一種中間系統，它從一個或多個源中接收RTP包，可能會改變其數據格式，再按某種方式把這些包組合成一個新的包，然后轉發出去。由于多個輸入源的計時一般不同步，所以混頻器對各個流的計時做出調整，并為組合流生成一個新的計時。

轉換器(Translator)也一種中間系統，它轉發RTP包而不改變包的同步源標識符。轉換器的例子如，不做混頻的轉碼器，多播復制到單播的重復裝置，以及防火墻里應用層次的過濾器。

RTP數據協議負責對流媒體數據進行封包并實現媒體流的實時傳輸，每一個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節的含義是固定的，而負載則可以是音頻或者視頻數據。

RTP報頭格式如下：

報頭的前12bits出現在每個RTP包中，僅僅在使用混合器插入時，才出現CSRC識別符列表。報頭各個域的含義解釋如下：

• 版本(V)：2 bits，定義了RTP的版本，以上版本為2。
• 填充(P)：1 bit，若被置為1，則此RTP包包含一個到多個附加在末端的填充比特，填充比特不作為負載的一部分。填充可能用于某些固定長度的加密算法，或者用于在低層數據單元中傳輸多個RTP包。
  
• 擴展(X)：1 bit，若設置擴展比特，則固定報頭后面跟隨一個擴展報頭。
  
• CSRC計數(CC)：4 bit，CSRC計數包含了跟在固定頭后面CSRC識別符的數目。
  
• 標志(M)：1 bit，含義由具體協議規定，它用來允許在比特流中標記重要的事件，如幀邊界。
  

• 負載類型(PT)：7 bits，定義了負載的格式，由具體應用決定其含義。協議可以規定負載類型碼和負載格式之間一個默認的匹配，其他的負載類型碼可以通過非RTP方法動態定義。RTP發送端在任意給定時間發出一個單獨的RTP負載類型，此域不用來復用不同的媒體流。例如我們常用的開源框架FFMPEG中，有以下支持的負載類型：

static const struct {int pt;const char enc_name[6];enum AVMediaType codec_type;enum AVCodecID codec_id;int clock_rate;int audio_channels; } rtp_payload_types[] = {{0, "PCMU", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_PCM_MULAW, 8000, 1},{3, "GSM", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},{4, "G723", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_G723_1, 8000, 1},{5, "DVI4", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},{6, "DVI4", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 16000, 1},{7, "LPC", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},{8, "PCMA", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_PCM_ALAW, 8000, 1},{9, "G722", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_ADPCM_G722, 8000, 1},{10, "L16", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_PCM_S16BE, 44100, 2},{11, "L16", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_PCM_S16BE, 44100, 1},{12, "QCELP", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_QCELP, 8000, 1},{13, "CN", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},{14, "MPA", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP2, -1, -1},{14, "MPA", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_MP3, -1, -1},{15, "G728", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},{16, "DVI4", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 11025, 1},{17, "DVI4", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 22050, 1},{18, "G729", AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_NONE, 8000, 1},{25, "CelB", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_NONE, 90000, -1},{26, "JPEG", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MJPEG, 90000, -1},{28, "nv", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_NONE, 90000, -1},{31, "H261", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H261, 90000, -1},{32, "MPV", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG1VIDEO, 90000, -1},{32, "MPV", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO, 90000, -1},{33, "MP2T", AVMEDIA_TYPE_DATA, AV_CODEC_ID_MPEG2TS, 90000, -1},{34, "H263", AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H263, 90000, -1},{-1, "", AVMEDIA_TYPE_UNKNOWN, AV_CODEC_ID_NONE, -1, -1} };

• 序列號(Sequence Number)：16 bits，每發送一個RTP數據包，序列號增1，接收端可以據此檢測丟包和重建包序列。序列號初始值是隨機的。
  

• 時間戳(Timestamp)：32 bits，反映了RTP數據包中第一個字節的采樣時間。時鐘頻率依賴于負載數據格式，并在描述文件(profile)中進行描述，也可以通過RTP方法對負載格式動態描述。時間戳的初始值應當是隨機的，就像序列號一樣。同時產生的幾個連續的RTP包，例如屬于同一個視頻幀的RTP包，將有相同的時間戳。不同媒體流的RTP時間戳可能會有獨立的隨機偏移量，并且可能以不同的速率增長，因此需要與參考時鐘上的時間戳(NTP)相關聯來實現不同媒體時間上的同步。
  

• 同步源(SSRC)：32 bits，用于識別同步源，是一個隨機數。來自同一信號源的包流發送方，例如麥克風、攝影機等就是同步源。如果參與者在一個會話中生成了多個流，例如這些流來自多個攝像機，則每個流都必須標識成單獨的同步源。若一個源改變本身的源傳輸地址，必須選擇新的SSRC標識符。一個同步源的所有包構成了相同計時和序列號空間的一部分，這樣接收方就可以把一個同步源的包放在一起進行重放。SSRC的綁定通過RTCP。
  

• 作用源(CSRC)列表：0~15個，每個32 bits，用于標識該RTP包中的作用源。標識符的數目在CC域中給定，若作用源多于15個，則僅識別15個。若一個RTP包流的源，對RTP混頻器生成的組合流起了作用，則它是一個作用源。對特定包的生成起作用的源組成的SSRC列表，被混頻器插入到包的RTP報頭中，即CSRC列表。
  

前面我們提到，若擴展位X的1 bit被置位，則固定報頭后面跟隨一個頭擴展(header extension)，下面我們就來看看頭擴展是個什么東東。

RTP提供了一個擴展機制以實現定制化：某些與負載格式獨立的新功能的附加信息可以在頭擴展中傳輸。頭擴展格式如下，

若RTP頭中的擴展比特位置1，則一個長度可變的頭擴展部分被添加到固定RTP頭之后。頭擴展包含16 bits的長度域，指示32 bits header extension字的個數，不包含4個字節擴展頭。length域之前的16 bits域是為了在多個互操作獨立生成不同的頭擴展時，用以識別各個頭擴展的標識符或參數，該16 bits的格式由具體實現的上層協議定義。

RTCP

下面我們來簡單介紹一下RTCP協議，RTCP雖然占用流量很少，但其實現邏輯較RTP復雜得多，因此，本篇限于篇幅，只介紹一下基礎概念，后面再開一篇專門介紹RTCP。

控制協議RTCP，用于QoS反饋和同步流媒體，相對RTP來說，RTCP所占帶寬非常小，通常只有5%。RTCP控制協議需要與RTP數據協議一起配合使用，當應用程序啟動一個RTP會話時將同時占用兩個端口，分別供RTP和RTCP使用。RTP本身并不能為按序傳輸數據包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會采用與RTP相同的分發機制，向會話中的所有成員周期性地發送控制信息，應用程序通過接收這些數據，從中獲取會話參與者的相關資料，以及網絡狀況、分組丟失概率等反饋信息，從而能夠對服務質量進行控制或者對網絡狀況進行診斷。

RTCP協議的功能是通過不同的RTCP數據報來實現的，主要有如下幾種類型：

• SR：發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也可以是接收端。(SERVER定時間發送給CLIENT)。
• RR：接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。(SERVER接收CLIENT端發送過來的響應)。
• DES：源描述，主要功能是作為會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
  

• BYE：通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。

• APP：由應用程序自己定義，解決了RTCP的擴展性問題，并且為協議的實現者提供了很大的靈活性。
  

今天先寫到這里，周末愉快！ 本篇主要參考RFC3550。

總結

以上是生活随笔為你收集整理的网络流媒体协议之——RTP协议概述的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。