封装格局
H.264的两种打包/封装办法：字节流AnnexB格局 AVCC格局
放用于网络发送时，要封装成RTP格局
1. AnnexB格局（实时播放）
开始前缀（00000001或000001）＋NALU数据,绝大部分编码器的默认输入格局
-
- 3字节0x000001 单帧多slice（即单帧多个NALU）之间距离
- 4字节0x00000001 帧之间，或者SPS等之前
2. AVCC（存储）
解码器配置参数在一开始就配置好了，零碎能够很容易的辨认NALU的边界，不须要额定的起始码，缩小了资源的节约，同时能够在播放时调到视频的两头地位。这种格局通常被用于能够被随机拜访的多媒体数据，如存储在硬盘的文件。MP4、MKV通常用AVCC格局来存储。
AVCC格局不应用起始码作为NALU的分界，这种格局在每个NALU前都加上一个大端格局的前缀（1、2、4字节，代表NALU长度）
防字节竞争解决（Annxb和AVCC均有）：RBSP👉EBSP
>用起始码定位NALU边界存在一个问题，即NALU中可能存在与起始码雷同的数据。
>为了避免这个问题，在构建NALU时，须要在数据中的0x000000,0x000001,0x000002,0x000003中插入防竞争字节（Emulation Prevention Bytes)0x03，使其变为：
0x000000 = 0x0000 03 00
0x000001 = 0x0000 03 01
0x000002 = 0x0000 03 02
0x000003 = 0x0000 03 03
解码器在检测到0x000003时，将0x03摈弃，复原原始数据。3.RTP封装=12字节固定RTP包头 + 载荷（NALU）
rtp传输的是annexb的h264码流
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V： RTP协定的版本号，以后协定版本号为2。
P： 填充标记，如果P=1，则在该报文的尾部填充一个或多个额定的八位组，它们不是有效载荷的一部分。
X： 扩大标记，如果X=1，则在RTP报头后跟有一个扩大报头
CC: CSRC计数器，批示CSRC 标识符的个数。
Ｍ： 标记位（不同载荷含意不同，视频标记一帧的最初一个分片slice则=1,其余=0）
PT： 载荷类型RTP_PAYLOAD_RTSP 如GSM音频、JPEM图像等。例如H264=96
序列号： 用于标识发送者所发送的 RTP 报文的序列号，每发送一个报文，序号减少 1
工夫戳： 工夫戳反映了该 RTP 报文的第一个八位组的采样时刻。 接受者应用工夫戳来计算提早和抖动， 并进行同步控制。
SSRC:同步信源标识符 辨别是在和谁通信。值随机抉择，加入同一视频会议的两个同步信源的SSRC要雷同。
//特约信源(CSRC)标识符：每个CSRC标识符占32位，能够有0～15个。每个CSRC标识了蕴含在该RTP报文有效载荷中的所有特约信源。
发表回复