# 一、協議概述
H265的RTP封包遵守RFC7798協議標準,與H264的RTP封包協議類似,也分三種打包模式:
1、Single NAL Unit Packets:單一NALU單元模式,即一個RTP包僅由一個完整的NALU組成。
2、Aggregation Packets:當同一時間戳內的多個NALU數據,不足以太網的最大報文長度1500個字節,可以將這多個NALU數據,封裝在一個RTP報文內。
3、Fragmentation Units:當一個NALU數據就大于1500個字節,需要將該NALU數據拆分成幾塊,分別封裝在不同的RTP報文內。
# 二、打包詳解

首先介紹一下H265的NAL Unit Header定義。
F:1bit,必須是0。
Type:6bits,nal\_unit\_type。指明該NAL Unit類型,可以參見《T-REC-H.265-201504-I!!PDF-E》協議的nal\_unit\_type定義。指明該NAL是SPS,還是PPS,還是IDR幀等。
LayerId:6 bits,必須是0。
TID:3 bits。時間參考層ID。
## 1、Single NAL Unit Packets

這種模式下,PayloadHeader與上面的Figure1的NALUHeader定義完全一致。只是該NALU傳輸的是CRA或者BAL時,NALU Type會變一下。
DONL:Decoding Order Number。當使用多slice編碼模式時使用,用于判斷一幀的每個slice是否收齊。不過目前webrtc默認都是使用單slice編碼模式,所以封包時,沒有該字段。
## 2、Aggregation Packets
很明顯,若是所有NALU都打包成一個RTP的話,對帶寬是很大的浪費,所以當編碼一幀有多個NALU數據的時候(比如一個IDR幀,還會攜帶SPS、PPS、VPS、SEI等NALU數據),可以把這多個NALU數據都打包在一個RTP報文里面。但是需要控制打包報文總長度小于1500字節,否則會引起IP分片。
### AP模式載荷頭格式定義

F:1bit,
Type:6bits,必須為48,表示是AP報文。
LayerId:6 bits,
TID:3 bits。
### AP模式首個NALU格式

### AP模式非首個NALU格式

### 不攜帶DONL字段的AP報文示例

## 3、Fragmentation Units
同樣,當編碼一幀數據長度大于1500個字節的時候,一個RTP報文裝不下一幀視頻數據,需要將該NALU數據拆分N份,封包到N個RTP報文里面去。
### FU模式載荷頭格式定義

F:1bit。
Type:6bits,必須為49,表示是FU報文。
LayerId:6 bits,
TID:3 bits。
### FU Header格式定義

S:1bit。1:表示是首個分片報文。0:非首個分片報文。
E:1bit。1:表示最后一個分片報文。0:非最后一個分片報文。
FuType:6 bits。該分片報文對應的NALU type。
# 三、參考
RFC7798
- 序言
- 編解碼
- H264
- HEVC碼流解析
- H264編碼原理
- 多媒體封裝
- MP4
- 學好 MP4,讓直播更給力
- AAC
- FLV
- 流媒體協議
- RTSP
- RTCP
- RTP
- H265 RTP封包筆記
- SDP
- RTMP
- RTMP URL
- rtmp url基礎
- webrtc
- 編譯
- 最簡單的編譯webrtc方案
- Webrtc音視頻會議之Webrtc“不求甚解”
- Webrtc音視頻會議之Mesh/MCU/SFU三種架構
- 音頻傳輸之Jitter Buffer設計與實現
- Janus
- Webrtc音視頻會議之Janus編譯
- Webrtc音視頻會議之Janus源碼架構設計
- webrtc服務器-janus房間管理
- 源碼分析
- WebRTC視頻JitterBuffer詳解
- 走讀Webrtc 中的視頻JitterBuffer(一)
- 走讀webrtc 中的視頻JitterBuffer(二)
- webrtc視頻幀率控制算法機制
- 目標碼率丟幀-1
- 目標幀率丟幀-2
- 29 如何使用Medooze 實現多方視頻會議
- FFmpeg
- FFmpeg編譯
- Window10下編譯最新版FFmpeg的方法步驟
- FFMPEG靜態庫編譯
- ffmpeg實現畫中畫
- FFmpeg推流器
- ffmpeg-aac
- OpenCV
- OpenCV學習筆記——視頻的邊緣檢測
- 圖像特征點匹配(視頻質量診斷、畫面抖動檢測)
- 圖像質量診斷