【音视频】H.264

封装格式

H.264的两种打包/封装方法：字节流AnnexB格式 AVCC格式
放用于网络发送时，要封装成RTP格式

1. AnnexB格式（实时播放）

开始前缀（00000001或000001）＋NALU数据,绝大部分编码器的默认输出格式

2. 1. 3字节0x000001　　单帧多slice（即单帧多个NALU）之间间隔
3. 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报文有效载荷中的所有特约信源。

档次(Profile)

为了适应不同的应用场景，H.264还定义了多种不同的档次。

• 基准档次（Baseline Profile）：主要用于视频会议、可视电话等低延时实时通信领域。支持I条带和P条带，熵编码支持CAVLC算法。
• 主要档次（Main Profile）：主要用于数字电视广播、数字视频数据存储等。支持视频场编码、B条带双向预测和加权预测，熵编码支持CAVLC算法和CABAC算法。
• 扩展档次（Extended Profile）：主要用于网络视频直播与点播等。支持基准档次的所有特性，并支持SI条带和SP条带，支持数据分割以改进误码性能，支持B条带和加权预测，但熵编码不支持CABAC算法和场编码
• 高档次（High Profile）：适用于高压缩率和性能场景；支持Main Profile的所有特性，以及8像素×8像素的帧内预测、自定义量化、无损压缩格式和YUV采样格式等。

比如H264BSD这个库，它只能解码基准档次的H264流。

举个RTSP协议的例子,在RTSP的DESCRIBE响应请求：

RTSP/1.0 200 OK
CSeq: 0
Content-Type: application/sdp
Content-Base: rtsp://myserver/live.mp4
Date: Wed, 16 Jul 2008 12:48:47 GMT
Content-Length: 847
v=0//以下都是SDP信息
o=- 1216212527554872 1216212527554872 IN IP4 myserver
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:50064
t=0 0
a=control:rtsp://myserver/live.mp4
&resolution=640x480
a=range:npt=0.000000-
m=video 0 RTP/AVP 96 //m表示媒体描述, 下面是对会话中视频通道的媒体描述
b=AS:50000
a=framerate:30.0
a=control:rtsp://myserver/live.mp4?trackID=1//trackID＝1表示视频流用的是通道1
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeKQFAe2AtwEBAaQeJEV,aM48gA==
m=audio 0 RTP/AVP 97//m表示媒体描述, 下面是对会话中音频通道的媒体描述
b=AS:64
a=control:rtsp://myserver/live.mp4?trackID=2//trackID＝2表示视频流用的是通道2
a=rtpmap:97 mpeg4-generic/16000/1
a=fmtp:97 profile-level-id=15; mode=AAC-hbr;config=1408; SizeLength=13; IndexLength=3;IndexDeltaLength=3; Profile=1; bitrate=64000;

由profile-level-id=420029;,可以得出

• profile_idc 0x42 == 66 (Baseline profile)
• profile-iop 0X00
• level-idc 0X29 == 41 (Level 4.1)

H.264的Profile和Level有哪些？

这个就不赘述了，在以下2个链接有详尽的列表：
https://en.wikipedia.org/wiki...
https://en.wikipedia.org/wiki...

可以參考這個库

参考文章

• 视频编码 H.264
• 关于H.264 profile-level-id