h264碼流在RTP中的傳輸(基於rfc3984)
Timestamp: 時間戳 32 bits
synchronization source (SSRC) identifier:同步源標誌
contributing source (CSRC) identifiers:一般不用,作用源列表
H.264 Payload 格式定義了三種不同的基本的負載(Payload)結構. 接收端可能通過 RTP Payload
的第一個位元組來識別它們. 這一個位元組類似 NALU 頭的格式, 而這個頭結構的 NAL 單元型別欄位
則指出了代表的是哪一種結構,
這個位元組的結構如下, 可以看出它和 H.264 的 NALU 頭結構(畢厚傑那本書上的)是一樣的.
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
欄位 Type: 這個 RTP payload 中 NAL 單元的型別. 這個欄位和 H.264 中型別欄位的區別是, 當 type
的值為 24 ~ 31 表示這是一個特別格式的 NAL 單元, 而 H.264 中, 只取 1~23 是有效的值.
24 STAP-A 單一時間的組合包(Single-time aggregation packet)
25 STAP-B 單一時間的組合包
26 MTAP16 多個時間的組合包(Multi-time
aggregation packet)
27 MTAP24 多個時間的組合包
28 FU-A 分片的單元 (Fragmentation unit)
29 FU-B 分片的單元
30-31 沒有定義
注意:上面這個表中,欄位的型別,指的是RTP中的。
可能的結構型別分別有:
1. 單一 NAL 單元模式
即一個 RTP 包僅由一個完整的 NALU 組成. 這種情況下 RTP NAL 頭型別欄位和原始的 H.264的 NALU 頭型別欄位是一樣的.
2. 組合封包模式
即可能是由多個 NAL 單元組成一個 RTP 包. 分別有4種組合方式: STAP-A, STAP-B, MTAP16, MTAP24.
那麼這裡的型別值分別是 24, 25, 26 以及 27.
3. 分片封包模式(MTU限制時用此法拆包)
用於把一個 NALU 單元封裝成多個 RTP 包. 存在兩種型別 FU-A 和 FU-B. 型別值分別是 28 和 29.
2.1 單一 NAL 單元模式
對於 NALU 的長度小於 MTU 大小的包, 一般採用單一 NAL 單元模式.
對於一個原始的 H.264 NALU 單元常由 [Start Code] [NALU Header] [NALU Payload] 三部分組成, 其中 Start Code 用於標示這是一個NALU 單元的開始, 必須是 "00 00 00 01" 或 "00 00 01", NALU 頭僅一個位元組, 其後都是 NALU 單元內容.
打包時去除 "00 00 01" 或 "00 00 00 01" 的開始碼, 把其他資料封裝成 RTP 包即可.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| 位元組2到n of a Single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上圖中第一位元組,是RTP的那一個位元組,而不是h264的NALU Header
如有一個 H.264 的 NALU 是這樣的:
[00 00 00 01 6742 A0 1E 23 56 0E 2F ... ]
這是一個序列引數集 NAL 單元. [00 00 00 01] 是四個位元組的開始碼, 67 是 NALU 頭, 42 開始的資料是 NALU 內容.
封裝成 RTP 包將如下:
[ RTP Header(12位元組) ] [ 67 42 A0 1E 23 56 0E 2F ]
即只要去掉 4 個位元組的開始碼就可以了.
2.2 組合封包模式
其次, 當 NALU 的長度特別小時, 可以把幾個 NALU 單元封在一個 RTP 包中.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header(12位元組固定頭) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR | NALU 1 的大小 | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 的資料 |
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 的大小 | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 的資料 |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3 Fragmentation Units (FUs).
而當 NALU 的長度超過 MTU 時, 就必須對 NALU 單元進行分片封包. 也稱為 Fragmentation Units (FUs).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. RTP payload format for FU-A
The FU indicator octet has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
The FU header has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
3. SDP 引數
下面描述瞭如何在 SDP 中表示一個 H.264 流:
. "m=" 行中的媒體名必須是 "video"
. "a=rtpmap" 行中的編碼名稱必須是 "H264".
. "a=rtpmap" 行中的時鐘頻率必須是 90000.
. 其他引數都包括在 "a=fmtp" 行中.
如:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
下面介紹一些常用的引數.
3.1 packetization-mode:
表示支援的封包模式.
當 packetization-mode 的值為 0 時或不存在時, 必須使用單一 NALU 單元模式.
當 packetization-mode 的值為 1 時必須使用非交錯(non-interleaved)封包模式.
當 packetization-mode 的值為 2 時必須使用交錯(interleaved)封包模式.
這個引數不可以取其他的值.
3.2 sprop-parameter-sets:
這個引數可以用於傳輸 H.264 的序列引數集和影象引數 NAL 單元. 這個引數的值採用 Base64 進行編碼. 不同的引數集間用","號隔開.
3.3 profile-level-id:
這個引數用於指示 H.264 流的 profile 型別和級別. 由 Base16(十六進位制) 表示的 3 個位元組. 第一個位元組表示 H.264 的 Profile 型別, 第
三個位元組表示 H.264 的 Profile 級別:
3.4 max-mbps:
這個引數的值是一個整型, 指出了每一秒最大的巨集塊處理速度.
相關推薦
h264碼流rtp打包(一)
一幀image編碼完的資料儲存在h264buffer中,編碼後的h264碼流的大小為nH264Size 因為對於NALU,並不是一幀對應一個NALU,而是對於SLICE而言,一個slice就封裝層一個nal,所以一幀可以有多個slice,即一幀有多個nal。
h264碼流在RTP中的傳輸(基於rfc3984)
Timestamp: 時間戳 32 bits synchronization source (SSRC) identifier:同步源標誌 contributing source (CSRC) identifiers:一般不用,作用源列表 H.264 Payload 格式定義了三種不同的
Wireshark提取RTP包中的H264碼流
1-- Dump RTP h.264 payload to raw h.264 file (*.264) 2-- According to RFC3984 to dissector H264 payload of RTP to NALU, and write it 3--
H264碼流中SPS PPS詳解<轉>
擴展 vlc 地址 逗號 部分 級別 軟件 第一個 bottom 轉載地址:https://zhuanlan.zhihu.com/p/27896239 1 SPS和PPS從何處而來? 2 SPS和PPS中的每個參數起什麽作用? 3 如何解析SDP中
H264碼流中SPS PPS詳解
轉載地址:https://zhuanlan.zhihu.com/p/27896239 1 SPS和PPS從何處而來? 2 SPS和PPS中的每個引數起什麼作用? 3 如何解析SDP中包含的H.264的SPS和PPS串? 1 客戶端抓包 在做客戶端視訊解碼時,一
將H264碼流打包成RTP包
H264碼流打包成RTP包的程式碼如下:#include <stdio.h> #include <stdlib.h> #include <conio.h> #include <string.h> #incl
RTP協議全解析(H264碼流和PS流)
寫在前面:RTP的解析,網上找了很多資料,但是都不全,所以我力圖整理出一個比較全面的解析, 其中借鑑了很多文章,我都列在了文章最後,在此表示感謝。 網際網路的發展離不開大家的無私奉獻,我決定從我做起,希望大家支援。 1、RTP Header解析
實現對rtp H264碼流的組幀
rtp打包h264,包含了三種類型的包: 一個rtp包攜帶了一幀資料(single) 多個rtp包攜帶了一幀資料(FU-A) 一個rtp包攜帶了多幀資料(STAP-A) 在實際應用中絕大部分採用的是前兩種方式,對方式1常見的是對nalu的sps,pps進行打包
RTP協議解析和H264碼流提取
一、 h264基礎概念SODB: 資料位元串-->最原始的編碼資料RBSP: 原始位元組序列載荷-->在SODB的後面填加了結尾位元(RBSP trailing bits 一個bit“1”)若干位元“0”,以便位元組對齊。EBSP: 擴充套件位元組序列載荷– >在RBS
從wireshark中獲取H264碼流詳解
1、首先從https://github.com/volvet/h264extractor打包下載 2、讀README.md 全文如下: # h264extractor wireshark plugin to extract h264 stream from rt
【視訊開發】【Live555】live555實現h264碼流RTSP傳輸
1.概述 liveMedia 庫中有一系列類,基類是Medium,這些類針對不同的流媒體型別和編碼。 其中的StreamFrame類檔案(如MPEG4VideoStreamFramer)為流傳輸關鍵。 2 重要概念: StreamFrame類:該類繼承Framed
流媒體開發: RTP協議全解析(H264碼流和PS流)
1、RTP Header解析
H264碼流結構分析和rtp打包結構詳解
網路抽象層單元型別 (NALU): NALU頭由一個位元組組成,它的語法如下: +---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |F|NRI| Type | +---------
RTP協議全解析(H264碼流以及PS流荷載)
寫在前面:RTP的解析,網上找了很多資料,但是都不全,所以我力圖整理出一個比較全面的解析,其中借鑑了很多文章,我都列在了文章最後,在此表示感謝。網際網路的發展離不開大家的無私奉獻,我決定從我做起,希望大家支援。1、RTP Header解析
FFMPEG 實時解碼網路H264碼流,RTP封裝
初學FFMPEG和H264,解碼視訊流時遇到了很多麻煩,記錄一下研究成果。 我使用的FFMPEG 2.5.2版本,使用av_parser_parse2重組影象幀時遇到了一下麻煩! 下面是主要程式碼: RTP頭定義, typedef struct { /**/
如何判斷h264碼流中的I幀和P幀
如何判斷碼流中的I幀和P幀 if(pData[i] == 0 && pData[i+1] == 0 && pData[i+2] == 0 &&
關於對H264碼流的PS的封裝的相關代碼實現
真心 clip gef 但是 占用 udp 大致 結果 方法 轉自:http://www.cnblogs.com/lidabo/p/6604988.html 1、寫在開始之前: 最近因為新工作要維護別人留下的GB模塊代碼,先熟悉了流程,然後也試著封裝
關於對H264碼流的TS的封裝的相關代碼實現
有效 當前 完成 read ble tco and mark comm 轉自:http://www.cnblogs.com/lidabo/p/6604998.html 1 寫在開始之前 在前段時間有分享一個H264封裝ps流到相關文章的,這次和
FFmpeg In Android - H264碼流解碼/OpenGL ES渲染
主要思路是FFmpeg解碼H264得到一張yuv420p圖片後,傳遞給opengl es在著色器內部做圖片轉換yuv->rgb,然後通過紋理貼圖的方式渲染出來.這種方式的效率更高.核心程式碼如下: #include "common.h" #include "gl_util.h"
FFmpeg In Android - H264碼流解碼/儲存Yuv
本節例子原始碼_NativeH264Android,修改自ffmpeg原始碼目錄/doc/examples/decode_video.c H264的碼流結構 H.264原始碼流(又稱為“裸流”)是由一個一個的NALU組成的,包括I幀,B幀,P幀等等,他們的結構如下圖所示: 其中每個