h264数据通过RTP分片传输的例子

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/wwyyxx26/article/details/50688590

使用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   |
      +---------------+


FU:Fragmentation Units


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


展开阅读全文

没有更多推荐了,返回首页