使用RTP传输H264数据时,当NALU的长度太长需要分包时,如下是一个例子,如想知道更详细的协议说明可以参考末尾连接。
在live555内部,收到一段数据每包开头如下
7c 81 e1 42
7c 1 d 8f
7c 1 a7 c8
7c 1 28 2d
。。。
7c 1 6b fb
7c 1 14 2b
7c 41 43 3b
live555将以上数据处理,得到的数据如下返回给使用者
61, e1, 42, 19, ff, 7f, 04, 8b, 99, 5c, 3
这是一个264的p帧
数据的第一个字节7c是FU indicator
第二个字节81, 1, 41等是FU header
The FU indicator octet has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
The FU header has the following format:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
7c写为二进制是01111100,即是:
0 11 11100
F 禁止位是0(0)
NRI 重要性指示位是 3(11)
NALU 类型是28(11100),FU-A型的分片的单元
81写为二进制是10000001,即是:
1 0 0 00001
S: 设置为1时表示是一个NALU的起始包,这里是1,说明是起始包
E: 设置为1时表示是一个NALU的结束包,这里是0,说明不是结束包
R: 保留位
Type: 载荷的类型,这里是1,因为是对264的分包,因此是说明载荷是264的非IDR图像的片
41写为二进制是01000001,即是:
0 1 0 00001
S: 设置为1时表示是一个NALU的起始包,这里是0,说明不是起始包
E: 设置为1时表示是一个NALU的结束包,这里是1,说明是结束包
Type: 载荷的类型,这里是1,因为是对264的分包,因此是说明载荷是264的非IDR图像的片
在接收完一包数据后组包,得到264的NALU头61,写为二进制是01100001,即是:
0 11 00001
禁止位同FU indicator的禁止位
重要性指示位同FU indicator的重要性指示位
类型同FU header的类型说明
以上是分包时的例子,不分包时则收到的数据直接就是:
61, e1, 42, 19, ff, 7f, 04, 8b, 99, 5c, 3
STAP-B and FU-B structures include DON
DON: Decoding Order Number
http://www.rfc-editor.org/rfc/rfc3984.txt
http://blog.csdn.net/yaorongzhen123/article/details/8453174
http://www.cppblog.com/czanyou/archive/2009/12/25/67940.html