一、H.264 的层次介绍
H.264 定义三个层次,每一个层次支持一组特定的编码功能。而且按照各个层次指定所指定的功能。基础层次(baselineprofile)支持 I 帧和 P 帧【1】的帧内和帧间编码,支持自适应的可变长度的熵编码(CAVLC)。主要层次(main profile)支持隔行扫描视频。B 帧【2】的帧内编码。使用加权预測的帧内编码和使用上下文的算术编码(CABAV)。扩展层次(extendedprofile)不支持隔行扫描视频和CABAC,但添加了码流之间高效的转化模式(SP 和 SI 片)和增强了错误码的恢复能力(数据切割)。基础层次的潜在应用主要包含可视电话、视频会议和无线通讯;主要层次的应用在电视广播和视频存储;扩展层次主要应用在流媒体应用程序中。然而,每一个文件有足够的灵活性,支持广泛的应用,这些应用的实例。不应被视为终于固定的。
二、H.264 的分层结构
H264 将其功能主要分为两层,即视频编码层(VCL)和网络提取层(NAL, Network Abstraction Layer)。VCL层负责编码。NAL层负责网络传输。
H.264 的视频提取层 NAL
H.264 的视频编码序列是由一系列的NAL 单元组成的。
我们知道00 00 00 01是NALU的開始标记
1. 网络抽象层单元类型 (NALU)
NALU 头由一个字节组成,它的语法例如以下:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI|Type |
+---------------+
F: 1 个比特(bit ).
forbidden_zero_bit.在 H.264规范中规定了这一位必须为 0.
NRI:2 个比特. nal_ref_idc.取 00 ~ 11,似乎指示这个
NALU的重要性,如 00的
NALU解码器能够丢弃它而不影响图像的回放.只是普通情况下不太关心这个属性.
Type:5 个比特.
nal_unit_type.这个 NALU单元的类型.简述例如以下:
0 未定义
1-23NAL单元单个 NAL单元包.
24STAP-A 单一时间的组合包
24STAP-B 单一时间的组合包
26MTAP16 多个时间的组合包
27MTAP24 多个时间的组合包
28FU-A 分片的单元
29FU-B 分片的单元
30-31未定义
2. 打包模式rfc3550
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP包头格式
前12个字节出如今每一个RTP包中,只在被混合器插入时。才出现CSRC识别符列表。
这些域有下面意义:
版本号(V):2比特 此域定义了RTP的版本号。此协议定义的版本号是2。(值1被RTP草案版本号使用。值0用在最初"vat"语音工具使用的协议中。
)
填充(P):1比特 若填料比特被设置。则此包包括一到多个附加在末端的填充比特,填充比特不算作负载的一部分。
填充的最后一个字节指明能够忽略多少个填充比特。
填充可能用于某些具有固定长度的加密算法,或者用于在底层数据单元中传输多个RTP包。
扩展(X):1比特 若设置扩展比特。固定头(仅)后面尾随一个头扩展。
CSRC计数(CC):4比特 CSRC计数包括了跟在固定头后面CSRC识别符的数目。
标志(M):1比特 标志的解释由详细协议规定。它用来同意在比特流中标记重要的事件,如帧边界。
负载类型(PT):7比特 此域定义了负载的格式,由详细应用决定其解释。协议能够规定负载类型码和负载格式之间一个默认的匹配。其它的负载类型码能够通过非RTP方法动态定义。
RTP发送端在随意给定时间发出一个单独的RTP负载类型;此域不用来复用不同的媒体流。
序列号(sequence number):16比特 每发送一个RTP数据包,序列号加1,接收端能够据此检測丢包和重建包序列。序列号的初始值是随机的(不可预測),以使即便在源本身不加密时(有时包要通过翻译器。它会这样做),对加密算法泛知的普通文本攻击也会更加困难。
时间戳(timestamp) 32比特 时间戳反映了RTP数据包中第一个字节的採样时间。
SSRC:32比特 用以识别同步源。
标识符应该被随机生成,以使在同一个RTP会话期中没有不论什么两个同步源有同样的SSRC识别符。
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是有效的值.
24STAP-A 单一时间的组合包
24STAP-B 单一时间的组合包
26MTAP16 多个时间的组合包
27MTAP24 多个时间的组合包
28FU-A 分片的单元
29FU-B 分片的单元
30-31未定义
可能的结构类型分别有:
1. 单一 NAL单元模式
即一个 RTP包仅由一个完整的 NALU组成.这样的情况下
RTP NAL头类型字段和原始的 H.264的
NALU 头类型字段是一样的.
2. 组合封包模式
就可以能是由多个 NAL单元组成一个 RTP包.分别有4种组合方式:
STAP-A, STAP-B, MTAP16, MTAP24.
那么这里的类型值各自是 24, 25, 26以及 27.
3. 分片封包模式
用于把一个 NALU单元封装成多个 RTP包.存在两种类型
FU-A和 FU-B.类型值各自是 28和
29.
2.1 单一 NAL单元模式(Single NAL Unit Packet:一个RTP
Payload仅包括一个NAL单元, NALU类型号为1~23,和H264标准码流很接近.)
对于 NALU的长度小于 MTU大小的包,一般採用单一
NAL单元模式.对于一个原始的 H.264 NALU单元常由
[Start Code] [NALU Header][NALU Payload]三部分组成,当中 StartCode用于标示这是一个NALU单元的開始,必须是
"00 00 00 01"或"00 00 01", NALU头仅一个字节,其后都是
NALU单元内容.
打包时去除 "00 00 01"或"00 00 00 01"的開始码,把其它数据封包的
RTP包就可以.
0 1 23
0 1 23 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 | |
+-+-+-+-+-+-+-+-+|
| |
|Bytes 2..n of a Single NAL unit |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|:...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
如有一个 H.264的 NALU是这种:
[0000 00 01 67 42 A0 1E 23 56 0E 2F ... ]
这是一个序列參数集 NAL单元. [00 00 00 01]是四个字节的開始码,
67是 NALU头, 42開始的数据是
NALU内容.
封装成 RTP包将例如以下:
[ RTPHeader ] [ 67 42 A0 1E 23 56 0E 2F ]
即仅仅要去掉 4个字节的開始码就能够了.
2.2 组合封包模式(Aggregation packet:一个RTP Payload包括多个NAL单元.有STAP-A,
STAP-B, MTAP-A,MTAP-B四种类型,编号依次为 24, 25,26, 27.)
其次,
当 NALU的长度特别小时,能够把几个
NALU单元封在一个 RTP包中.
0 1 23
0 1 23 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTPHeader |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-ANAL HDR | NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NALU 1 Data |
: :
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NALU 2 Data |
: :
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|:...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3Fragmentation Units (FUs).(Fragmentation unit:一个RTPPayload包括一个NAL单元的一部分.有FU-A,
FU-B两种,分别标记为 28, 29.)
而当 NALU的长度超过 MTU时,就必须对
NALU单元进行分片封包.也称为 Fragmentation Units (FUs).
0 1 23
0 1 23 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FUindicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| |
| FUpayload |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|:...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure14. RTP payload format for FU-A
TheFU indicator octet has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI|Type |
+---------------+
TheFU header has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R|Type |
+---------------+
{
1,将FU-A包依据rtp的包序号和FU-A的header字节,组成完整264帧。
2。推断帧类型假设是idr帧,须要在帧头加上sps和pps,格式为:
起始码(0x00000001)+sps+起始码+pps+起始码+完整帧数据
3。帧末加入帧间分隔符“0x00, 0x00, 0x01, 0x09, 0x10”
4,使用网上精简过的"ff_264_dec_vc"进行解码。
该项目不支持imgconvert,可从最新ff源代码查找
并拷贝yuv420p_to_xxx函数进行合适转码
}
3. SDP 參数【3】
以下描写叙述了怎样在 SDP中表示一个 H.264流:
."m=" 行中的媒体名必须是 "video"
."a=rtpmap" 行中的编码名称必须是 "H264".
."a=rtpmap" 行中的时钟频率必须是 90000.
. 其它參数都包含在 "a=fmtp"行中.
如:
m=video49170 RTP/AVP 98
a=rtpmap:98H264/90000
a=fmtp:98profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
以下介绍一些经常使用的參数.
3.1packetization-mode:表示支持的封包模式.
当 packetization-mode的值为 0时或不存在时,必须使用单一
NALU单元模式.
当 packetization-mode的值为 1时必须使用非交错(non-interleaved)封包模式.
当 packetization-mode的值为 2时必须使用交错(interleaved)封包模式.
这个參数不能够取其它的值.
3.2sprop-parameter-sets:
这个參数能够用于传输 H.264的序列參数集和图像參数 NAL单元.这个參数的值採用
Base64进行编码.不同的參数集间用","号隔开.
3.3profile-level-id:
这个參数用于指示 H.264流的 profile类型和级别.由
Base16(十六进制)表示的 3个字节.第一个字节表示
H.264的 Profile类型,第
三个字节表示 H.264的 Profile级别:
3.4max-mbps:
这个參数的值是一个整型,指出了每一秒最大的宏块处理速度.
问题一:怎样把h.264的包打包成rtp包?
答:打包时去除H.264的開始码,然后加上rtp头就可以.
RTP打包H.264过程
1.打开.264文件
2.设置初始化套接字
3.从264码流中推断起始码。先读前3个字节,看是不是0x000001,假设不是的话,再多读取一个字节,看前4个字节是不是0x00000001。
(读到156行)