H264關於RTP協議的實現

2021-06-16 23:42:08 字數 3202 閱讀 4523

tag: 

h264

rtprfc3984

端和客戶端分別進行了功能模組設計。

伺服器端:rtp封裝模組主要是對h.264碼流進行打包封裝;rtcp分析模組負責產牛和傳送rtcp包並分析接收到的rtcp包;qos反饋控制模組則根據rr報文反饋資訊動態的對傳送速率進行調整;傳送緩衝模組則設定埠傳送rtp、rtcp包。

客戶端:rtp模組對接收到的rtp包進行解析判斷;rtcp模組根據sr報文統計關鍵資訊,產牛並傳送rr包。然後,在vc++

。但是udp協議

本身是面向無連線的,不能提供質量保證。而基於udp之上的高層協議

rtp載荷封裝設計

本文的網路傳輸是基於ip協議,所以最大傳輸單元(mtu)

最大為1500位元組,在使用ip/udp/rtp的協議層次結構的時候,這其中包括至少20位元組的ip頭,8位元組的udp頭,以及12位元組的rtp頭。這樣,頭資訊至少要占用40個位元組,那麼rtp載荷的最大尺寸為1460位元組。

一方面,如果每個ip分組都填滿1500位元組,那麼協議頭的開銷為2.7%,如果rtp載荷的長度為730位元組,協議頭的開銷仍達到5.3%,而假設 rtp載荷的長度不到40位元組,那麼將有50%的開銷用於頭部,這將對網路造成嚴重資源浪費。另一方面,如果將要封裝進rtp載荷的資料大於1460字 節,並且我們沒有在應用層資料裝載迸rtp包之前進行載荷分割,將會產生大於mtu的包。在ip層其將會被分割成幾個小於mtu尺寸的包, 這樣將會無法檢測資料是否丟失。因為ip和udp協議都沒有提供分組到達的檢測,如果分割後第乙個包成功接收而後續的包丟失,由於只有第乙個包中包含有完 整的rtp頭資訊,而rtp頭中沒有關於載荷長度的標識,因此判斷不出該rtp包是否有分割丟失,只能認為完整的接收了。並且在ip層的分割無法在應用層 實現保護從而降低了非平等包含方案的效果。由於udp資料分組小於64k位元組,而且乙個片的長度對某些應用場合來說有點太小,所以應用層的打包也是rtp打包機制的乙個必要部分。最新的rfc3984標準中提供了針對h.246**流的rtp負載格式,主要有三種:

單個nal單元分組、聚合分組、片分組。

nal單元單一打包

將乙個nal單元封裝進乙個包中,也就是說rtp負載中只包含乙個nal單元,nal頭部兼作rtp頭部。rtp頭部型別即nal單元型別1-23,如下圖所示:

nal單元的重組

此分組型別用於將多個nal單元聚合在乙個rtp分組中。一些h.264的nal單元的大小,如sei nal單元、引數集等都非常小,有些只有幾個位元組,因此應該把它們組合到乙個rtp包中,將會有利於減小頭標(rtp/udp/ip)的開銷。目前存在著兩種型別聚合分組:

nal單元的分割

層vcl上的分割

為了適應網路mtu的尺寸,可以使用編碼器來選擇編碼slice nalu的大小,從而使其提供較好的效能。一般是對編碼slice的大小進行調整,使其小於1460位元組,以免ip層的分割。

2)網路提取層nal上的分割

在網路提取層上對nalu的分割主要是採用分片單元方案,h.264標準中提出了分割機制,可以使nal單元的尺寸小於1460位元組。注意:此方式是針對同乙個nal單元進行分割的,不適用於聚合分組。乙個nal單元採用分割分組後,每個rtp分組序列號依次遞增l,rtp時間戳相同且惟一。nal單元的分割是rtp打包機制的乙個重要環節,總結其分割機制主要有如下幾個特點:

①分割nalu時,是以rtp次序號公升序進行傳輸。在序列號不迴圈的前提下,屬於前一幀影象的所有影象片包以及a/b/c資料分割包的序列號要小於後幀影象中的影象片及資料分割包的序列號。

②乙個符號機制來標記乙個分割的nalu是第乙個還是最後乙個nal單元。

3.存在另外乙個符號機制用來檢測是否有丟失的分塊。

④輔助增強資訊包和頭資訊包可以任意時間傳送。

⑤同一幀影象中的影象片可以以任意順序傳送,但是對於低時延要求的網路系統,最好是以他們原始的編碼順序來傳送。

1)單一時間聚合分組(stap):包括單一時間聚合分組a(stap—a)和單一時間聚合分組b(stap—b),按時間戳進行組合,他們的nal單元具有相同的時間戳,一般用於低延遲環境。stap—astap—b的單元型別分別為24和25。

2)多時間聚合分組(mtap):包括16位元偏移多時間聚合分組(mtapl6)和24位元偏移多時間聚合分組 (mtap24)不同時間戳也可以組合,一般用於高延遲的網路環境,比如流**

應用.它的打包方案相對複雜,但是大大增強了基於流**

的h.264的性 能。mtapl6 mtap24的單元型別分別為26和27。

rtp包的封裝流程設計

根據h.264nal單元的分割重組的性質以及rtp打包規則,本文實行的對rtp打包的設計如下:

1、若接收到的nal單元小於max—size(此時max-size為設定的最大傳輸單元),則對它進行單一打包,也就是將此nal單元直接放進rtp包的載荷部分,生成乙個rtp包。

2、若接收到的nal單元大於max—size位元組,則對它進行分割,然後對分割後的nal單元進行步驟1方式打包。分割方案如下:

其中nsize是分割前的nal單元大小,n是分割後nal單元的大小。k分割後的單元數。分割後最後乙個單元的大小可能會小於n,這時必須使用rtp載荷填充是其同前面的分塊大小相同,此時rtp頭中的填充標識位值為1。

rtp/rtcp包的封裝實現

rtp包封裝設計

rtcp包的封裝設計

rtcp報文封裝在udp資料報中進行傳輸,傳送時使用比它所屬的rtp流的埠號大1的協議號(rtp使用偶數號,rtcp使用奇數號)。以下是rtcp頭部資料結構:

羅索實驗室 [

實現RTP協議的h 264傳輸

2.rtp 協議關鍵引數的設定 3.h.264 基本流結構及其傳輸機制 3.1 h.264 基本流的結構 f forbidden zero bit.1 位,如果有語法衝突,則為 1。當網路識別此單元存在位元錯誤時,可將其設為 1,以便接收方丟掉該單元。nri nal ref idc.2 位,用來指示...

實現RTP協議的h 264傳輸

1.引言 2.rtp 協議關鍵引數的設定 3.h.264 基本流結構及其傳輸機制 3.1 h.264 基本流的結構 f forbidden zero bit.1 位,如果有語法衝突,則為 1。當網路識別此單元存在位元錯誤時,可將其設為 1,以便接收方丟掉該單元。nri nal ref idc.2 位...

基於RTP協議的H 264傳輸

分類 linux 1.引言 2.rtp 協議關鍵引數的設定 3.h.264 基本流結構及其傳輸機制 3.1 h.264 基本流的結構 f forbidden zero bit.1 位,如果有語法衝突,則為 1。當網路識別此單元存在位元錯誤時,可將其設為 1,以便接收方丟掉該單元。nri nal re...