字节流格式（Annex B）和RTP格式流浅析

来源：互联网发布：async await js 编辑：程序博客网时间：2024/05/24 00:29

AnnexB格式：NALU数据+开始前缀（00000001或000001，此处注意为甚么是4bit或3bit，后面有描述）；针对H.320电话会议

RTP 格式：NALU数据+20个字节的类似的并不符合RTP协议的RTP头。针对IP网络的RTP打包方式

H.264协议只规定了字节流格式，没有规定 RTP 格式。可能也是因为这个原因，JM 的 RTP 格式没有被用到任何场合场合中，成为了摆设。下图中的 RTP 格式是h.264乐园的firstime从 JM86 中分析出来的。实际包交换网络中必须按照 RFC3984 将 NALU 数据封装为 RTP 包，而不能使用 JM 的 RTP 格式。

字节流格式（Annex <wbr>B）和RTP格式流浅析

下面引自“QUESTIONMARK”的博客

下面说明3字节起始码和4字节起始码。

以下和leading_zero_8bits、trailing_zero_8bits已无关系，忘掉。
   if( next_bits( 24 ) != 0x000001 )
        zero_byte                                      f(8)
    start_code_prefix_one_3bytes   f(24)
根据B.1节，可以看到所谓的4字节起始码是(zero_byte + 3字节起始码)。那么看zero_byte的说明，就可以明白zero_byte什么时候出现，也就能明白什么时候出现4字节起始码：
1. SPS、PPS nalu是4字节起始码；
2. Access Unit的首个nalu是4字节起始码（参见7.4.1.2.3）。
这里举个例子说明，用JM可以生成这样一段码流（不要使用JM8.6，它在这部分与标准不符），这个码流可以见本楼附件：
      SPS            （4字节头）
      PPS            （4字节头）
      SEI            （4字节头）
      I0(slice0)     （4字节头）
      I0(slice1)    （3字节头）
      P1(slice0)     （4字节头）
      P1(slice1)    （3字节头）
      P2(slice0)     （4字节头）
      P2(slice1)    （3字节头）
I0(slice0)是序列第一帧（I帧）的第一个slice，是当前Access Unit的首个nalu，所以是4字节头。而I0(slice1)表示第一帧的第二个slice，所以是3字节头。P1(slice0) 、P1(slice1)同理。

总结：
1 附录 B字节流在一个byte_stream_nal_unit的前后可能出现若干个0x00，仅用作填充之用。这个不常见。
2 4字节头只出现在SPS、PPS和7.4.1.2.3规定的Access Unit的首个nalu。其余情况都是3字节头

一共有两种起始码：3字节的0x000001和4字节的0x00000001
3字节的0x000001只有一种场合下使用，就是一个完整的帧被编为多个slice的时候，包含这些slice的nalu使用3字节起始码。其余场合都是4字节的。