【音视频】H.264

看见了

封装格式

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

1. AnnexB格式(实时播放)

开始前缀(00000001000001)+NALU数据,绝大部分编码器的默认输出格式

    1. 3字节0x000001  单帧多slice(即单帧多个NALU)之间间隔
  1. 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 标识符的个数。

M:    标记位(不同载荷含义不同,视频标记一帧的最后一个分片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...

可以參考這個

参考文章

阅读 338

solfKwolf的前端杂记
涉及个人学习心得与经验

i'm look for a good job :)

568 声望
10 粉丝
0 条评论

i'm look for a good job :)

568 声望
10 粉丝
文章目录
宣传栏