H264 的 RTP 格式封装

最新推荐文章于 2020-12-07 15:32:00 发布
最新推荐文章于 2020-12-07 15:32:00 发布
阅读量3.2k 收藏 17
点赞数 2
分类专栏： 音视频 标准协议 文章标签： RTP H264 视频 RFC
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yongkai0214/article/details/88872076
版权

H264 的 RTP 格式封装

H264 的 RTP 打包方式说明在网上已经很多了，一般都是按照标准协议 RFC 3984 或者 RFC 6184 的顺序来解释，也有通过代码来说明的。最近有同事遇到有关的问题来咨询，所以干脆再写一篇，换个顺序来说明。

RFC 6184/3984

RFC 3984 在 2005 年正式称为RFC，被非常大范围的采用，即使现在也是绝大多数的代码遵循的标准。RFC 6184 是在时隔六年以后于2011 年替代 RFC 3984，实际上这两篇 RFC 差别并不是很大，甚至很多人都没想过现在遵循的是谁，这也是因为后相兼容的好处。但是不管怎么说，修订版既然已经废弃了 RFC 3984，还是有必要了解新的协议。

和 RFC 3984 比较，全文有非常多的文字描述修改，比如were 改成 are 等之类的文字方面，也有一些技术细节的描述，这些技术细节主要集中在第 8 章。第 8 章是描述类似 profile-level-id，max-smbps 等之类的媒体字段。其他修改包括一些字段比如 packetization mode 在 RFC 3984 中 描述可以由带外信令携带，在 RFC 6184 中删除。所以纵观全文，改动并不大，但是描述将更准确。如果只是关注 H264 数据的打包，几乎可以不关注。

H264 简介

H264是现在应用范围最广的视频编解码算法，其中比较引人注目的是 x264，openH264 两个优秀的开源实现，解码一般用 ffmpeg。视频图像以帧为单位输入到编码器中，输出编码后的有损压缩码流。

为什么能压缩？压缩就是将图像中重复的细节或者近似的部分用精简的方式表达出来。最主要的相似在于帧间图像之间，其次是单帧图像内部。在足够短的以内采集两张图片，可以认为，这两张图片几乎相同，这就是时间序列上的相似。一般每秒采集的图像在30帧左右，图像上的差别仍然可以帮助节约非常大的数据流量。至于空间相似性，单张图片上的足够小的纹理范围的变化是非常小的，或者渐变的。通过减少相同内容，融合相似内容就可以实现压缩。

为什么是有损？为了最大限度的减少数据容量，还要保持更多的细节，还得加快运算速度，就可能扩大比较的范围，或者将非常小的变化忽略。打个比方，本来图像上有 1280 * 720 个像素点，但是感觉点太多，就将像素点每4个点取均值或中值代表，这样图像的点就大大减少，计算量也大大缩减。视觉冗余是指人们对一些色彩或细节并不敏感，所以不要也罢。

因为时间序列相似性的地位，在编码时，经常取某一帧为一个基准参考帧，不参考别人，只参考自己。后续帧以前一帧作为参考，这样，每张图像相对前一张都可以最大限度进行压缩。但是如果中间某一帧数据被丢失，可能就导致这个参考链条断裂，后来的所有帧参考出来的图像都有问题。就出现 GOP（Group of picture，图像组）的概念，隔一段时间就重新出现一个参考帧刷新一下，使错误不致传播。这就是 I（Intra-coded picture, 帧内编码图像帧）帧和 P （Predictive-coded Picture，预测编码图像帧）帧的关系。B （Bidirectionally predicted picture，双向预测编码图像帧）帧则是更近一步，不仅可以参考前面的，还可以参考后面的，更进一步提高压缩比。

但过多的 P，B 帧会使编码效率降低。为什么会降低？前面说了足够短的时间内，图像可以视为不变，但是场景总是可能切换的。切换前后会变化非常大，这个时候的图像变化就会很大了。还这么做，就要考虑是不是划算了，做事情，总得考虑性价比。不过这是使用编码器的人需要考虑的，H264 本身只是提供一种方法而已。

编码后每帧长度可能并不相同，那如何区分呢？每一个帧从编码器出来都会携带开始码八进制 00 00 00 01 或者 00 00 01。如果刚好出现 0x00，那就在帧间加上 0x03，在 H264 的机制名叫作 emulation prevention（防止竞争）。因为已经约定好了，所以解码器可以自动识别，不会产生歧义。

在 H264 中将图像组，或者图像本身宏块的一些公共参数抽象出来，独立起来传输，这一点在 H265 也保持下来了。这些参数分为两种，一种是序列参数集 SPS, 另一种是图像参数据 PPS。SPS 从名字就可以看出与整个序列有关。这个序列就是所处的这个 GOP，包括图像格式信息，编码参数信息，与参考图像相关的信息，档次、层和级相关信息等等。而 PPS 紧随 SPS，包含一幅图像所用的公共参数，即一幅图像中所有片段引用同一个 PPS。还存在一种数据，SEI 是 H264 标准中一个重要的技术，主要起补充和增强的作用。SEI 没有图像数据信息，只是对图像数据信息或者视频流的补充，有些内容可能对解码有帮助。

每一帧编码后的数据可以分成多个单元输出，也可以整体输出，每一个数据单元负责格式化数据并提供头信息，以保证数据适合各种信道和存储介质上的传输，这就是 NALU，也就是 NAL 单元。这个数据块是由一个字节的头和一系列来自编码层的称为原始字节序列载荷（RBSP）的字节流。

  +---------------+
  |0|1|2|3|4|5|6|7|
  +-+-+-+-+-+-+-+-+
  |F|NRI|  Type   |
  +---------------+
     NAL unit header

F: 1 bit, forbidden_zero_bit.

一般为0，为 1 时表示此单元出现错误，解码器会丢弃该数据，按丢包处理。

NRI: 2 bits, nal_ref_idc.

由编码器决定该 NAL 单元的优先级，值越高，优先级越高。00 时表示该帧不用于在重建参考图像的内部预测，可以丢弃。

 Table 2.  Example of NRI values for coded slices and coded slice
           data partitions of primary coded reference pictures

  NAL Unit Type     Content of NAL Unit              NRI (binary)
  ----------------------------------------------------------------
   1              non-IDR coded slice                         10
   2              Coded slice data partition A                10
   3              Coded slice data partition B                01
   4              Coded slice data partition C                01

       Informative note: As mentioned before, the NRI value of non-
       reference pictures is 00 as mandated by H.264.

Type:5 bits, nal_unit_type.

在网络中如何传输这些 NAL 单元，有不同的方式，常见的就是通过 RFC3984/RFC6184 定义的通过 RTP 打包的传输方式。一般情况下，在传输之前，需要事先协商好如何传输，传输什么内容。这种协商的描述方式采用 SDP 来完成。所以在会话协议中如 SIP, RTSP 等都会携带 SDP 的文本描述，使得双方完成意见交换，达成一致。

在协商过程中，除了对双方的 IP 地址，端口，编解码类型，PT 值，采样率等进行协商外，还有几个重要的参数，如 packetization-mode， profile-level-id，sprop-parameter-sets 等，这些值也在 RFC3984/RFC6184 有介绍。 如一个常见的 SDP 例中如下所示：

 m=video 49170 RTP/AVP 98
  a=rtpmap:98 H264/90000
  a=fmtp:98 profile-level-id=42A01E;
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data>

分包模式

本文主讲分包，所以其他的部分以后再说，在这里相关的是 packetization-mode 这个字段，不同的值代表支持不同的分包模式。如下：

  1. 单一NAL单元模式（ Single NAL unit mode）：packetization-mode = 0 或者无此字段时缺省
  2. 非交错模式（Non-interleaved mode）: packetization-mode = 1
  3. 交错模式（Interleaved mode）: packetization-mode = 2

这三种模式的概念是基于不同的应用场景提出来的，单一分包和非交错模式都是为通信系统，人与人对话交流的场景设计，所以必须考虑低时延，按照解码的顺序传递数据包，而交错模式的场景一般是对时延并不是特别敏感的场景，传递包的顺序也可以不按照解码顺序来。所以交错模式下的包中都需要携带一个 DON (Decoding order number)。

虽然从总体上分类 3 类，但是实际上打包的类型不止三种，所以每一种模式实际上可能包含好几种打包类型。从封包的内容上看，分为两类，第一类为 single NAL unit packet，第二类为 aggregation packets。从名字上就可以看出，第一类的包种包含一个 NALU，而第二类包可能聚合了不止一包，需要解包时在重组。

对于聚合包来说，又分为 STAP-A，STAP-B，MTAP16，MTAP24 四种包类型，从名字上可以看出分为 STAP (Single-time aggregation packet) 和 MTAP (Multi-time aggregation packet)，也就是包内包含的时间戳是否相同，对于不同时间戳的包，就需要在包头内携带与参照时间戳的差值，以及解码顺序号。

      Table 4.  Type field for STAPs and MTAPs

  Type   Packet    Timestamp offset   DON-related fields
                   field length       (DON, DONB, DOND)
                   (in bits)          present
  --------------------------------------------------------
  24     STAP-A       0                 no
  25     STAP-B       0                 yes
  26     MTAP16      16                 yes
  27     MTAP24      24                 yes

有些数据太长，需要分片成多个包时，就会按照一定规则分片。分片之间需要知道开始包是谁，结束包是谁，中间包怎么区分等待，这就是 FUs( Fragmentation Units)。按照上面例如 STAP-A 和 STAP-B 这样的区别，分为 FU-A 和 FU-B，具体的区别后面再描述。但是 FUs 定义的分片只能作用于单个 NALU，如果是聚合包则不能直接使用此分片。

说了这么多的打包类型，再回头说三种分包模式。

  1. 对于 Single NAL Unit Mode，仅含有 single NAL unit packet，所以一般都是较小的包，太大的包可能分片，也不能适用此场景。协议要求接收方必须支持，只能 say YES。
  2. 对于 Non-interleaved mode，包含 single NAL unit packets，STAP-As 和 FU-As，不能包含 STAP-Bs，MTAPs 和 FU-Bs。协议要求接收方应该支持，即在一般场景都应该支持。这也是现在应用最广的模式，在通信领域，在互联网通信基本上都会支持。
  3. 对于 Interleaved mode，包含 STAP-Bs，MTAPs，FU-As，and FU-Bs，不能存在 STAP-As 和 single NAL unit packets。协议要求接收方可以支持，即按照场景决定是否支持，可以选择 NO 。

下面是一个打包类型的汇总，也作为下一部分介绍的引子。

  Table.  Summary of allowed NAL unit types for each packetization
            mode (yes = allowed, no = disallowed, ig = ignore)
NAL Unit TypePacket TypePacket Type NameSingle NAL Unit ModeNon-Interleaved ModeInterleaved Mode
0reservedigigig
1-23NAL unitSingle NAL unit packetyesyesno
24STAP-ASingle-time aggregation packetnoyesno
25STAP-BSingle-time aggregation packetnonoyes
26MTAP16Multi-time aggregation packetnonoyes
27MTAP24Multi-time aggregation packetnonoyes
28FU-AFragmentation unitnoyesyes
29FU-BFragmentation unitnonoyes
30-31reservedigigig

打包类型

Single NAL Unit Packet

单 NALU 包比较简单，除了 RTP 头外，后面直接放上去掉开始码得 NALU 即可。如果要多个小包一起，又不想采用聚合包，那么小包之前得加上开始码，否则解码器不认识。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI|  Type   |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
|               Bytes 2..n of a single NAL unit                 |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2.  RTP payload format for single NAL unit packet

Agregation packet

聚合包与单NALU包比起来，差别还是在内容上，格式上起始基本上一致。如下所示。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI|  Type   |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
|             one or more aggregation units                     |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3.  RTP payload format for aggregation packets

单时间聚合-STAP

STAP-A 用于非交错模式。STAP-用于交错模式，它们结构上最大的区别是是否需要携带 DON，每个 NALU 都会有长度标识。DON 和 NALU Size 都是无符号整数，网络字节序形式。如下是两种包的 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         NALU 1 Data                           |
:                                                               :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | NALU 2 Size                   | NALU 2 HDR    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         NALU 2 Data                           |
:                                                               :
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7.  An example of an RTP packet including an STAP-A
           containing two single-time aggregation units

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-B NAL HDR | DON                           | NALU 1 Size   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size   | NALU 1 HDR    | NALU 1 Data                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
:                                                               :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | NALU 2 Size                   | NALU 2 HDR    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       NALU 2 Data                             |
:                                                               :
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8.  An example of an RTP packet including an STAP-B
           containing two single-time aggregation units

多时间聚合-MTAP

MTAP 聚合包与STAP比起来，差别最大的在头部。因为可能聚合多个不同时间的包，所以必须携带一个基准的 DON, timestamp。DOND 和 TS offset 是与基准的差值，这个基准应该是取自时间最早的那个 NALU 的值。DONB 和 NALU Size 为 16 位无符号整数，DOND 为 8 位无符号整数，TS offset 为 16 或者 24 位 无符号整数，均为网络字节序形式。

MTAP16 和 MTAP24 在本质上并没有什么差别，只是用了更多的位数来表达时间差，如果这个位数越多，可以容纳的时间戳差值越大，也就代表 MTAP 具有更大的扩展性，但是也占用了更多的头部字节，还是需要综合考虑性价比。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP16 NAL HDR |  decoding order number base   | NALU 1 Size   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NALU 1 Size  |  NALU 1 DOND  |       NALU 1 TS offset        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NALU 1 HDR   |  NALU 1 DATA                                  |
+-+-+-+-+-+-+-+-+                                               +
:                                                               :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | NALU 2 SIZE                   |  NALU 2 DOND  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       NALU 2 TS offset        |  NALU 2 HDR   |  NALU 2 DATA  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
:                                                               :
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12.  An RTP packet including a multi-time aggregation
            packet of type MTAP16 containing two multi-time
            aggregation units



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          RTP Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP24 NAL HDR |  decoding order number base   | NALU 1 Size   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NALU 1 Size  |  NALU 1 DOND  |       NALU 1 TS offs          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NALU 1 TS offs |  NALU 1 HDR   |  NALU 1 DATA                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
:                                                               :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | NALU 2 SIZE                   |  NALU 2 DOND  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       NALU 2 TS offset                        |  NALU 2 HDR   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  NALU 2 DATA                                                  |
:                                                               :
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13.  An RTP packet including a multi-time aggregation
            packet of type MTAP24 containing two multi-time
            aggregation units

分片单元-FUs

前面提到了 FUs 只能作用到一个 NALU 上，也就是对同一个 NALU 进行分片。在网络传输中，将大的数据单元改小是很有意义的，比如有利于包的传输，有利于纠错机制的使用等，在接收端必须按照分片方式重组。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator  |   FU header   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
|                         FU payload                            |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 14.  RTP payload format for FU-A

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator  |   FU header   |               DON             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                                                               |
|                         FU payload                            |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               :...OPTIONAL RTP padding        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 15.  RTP payload format for FU-B

同样分为两种格式 FU-A 和 FU-B，结构差别只在于一个 DON，相同的是都有两个头 FU indicator 和 FU header，大小都是一个字节。

  +---------------+
  |0|1|2|3|4|5|6|7|
  +-+-+-+-+-+-+-+-+
  |F|NRI|  Type   |
  +---------------+
   FU indicator format

  +---------------+
  |0|1|2|3|4|5|6|7|
  +-+-+-+-+-+-+-+-+
  |S|E|R|  Type   |
  +---------------+
   FU header format

分片单元不能用于传输一个分片，因为不能同时在一个 FU 头里面设置开始和结束标志。

其他

这篇文章只写了针对 TS 流的打包，而且对于协议中很多参数没有说明，有需要以后再仔细解释，这里简单列举一下。

   Table 6.  Interpretation of parameters for different direction
             attributes

                                          sendonly --+
                                       recvonly --+  |
                                    sendrecv --+  |  |
                                               |  |  |
            profile-level-id                   C  C  P
            max-recv-level                     R  R  -
            packetization-mode                 C  C  P
            sprop-deint-buf-req                P  -  P
            sprop-interleaving-depth           P  -  P
            sprop-max-don-diff                 P  -  P
            sprop-init-buf-time                P  -  P
            max-mbps                           R  R  -
            max-smbps                          R  R  -
            max-fs                             R  R  -
            max-cpb                            R  R  -
            max-dpb                            R  R  -
            max-br                             R  R  -
            redundant-pic-cap                  R  R  -
            deint-buf-cap                      R  R  -
            max-rcmd-nalu-size                 R  R  -
            sar-understood                     R  R  -
            sar-supported                      R  R  -
            in-band-parameter-sets             R  R  -
            use-level-src-parameter-sets       R  R  -
            level-asymmetry-allowed            O  -  -
            sprop-parameter-sets               S  -  S
            sprop-level-parameter-sets         S  -  S

         Legend:

         C: configuration for sending and receiving streams
         O: offer/answer mode
         P: properties of the stream to be sent
         R: receiver capabilities
         S: out-of-band parameter sets
         -: not usable (when present, SHOULD be ignored)
老雍
关注
  • 2
    点赞
  • 踩
  • 17
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
h264基础及rtp分包解包
machh的专栏
08-09 1万+
一、 h264基础概念SODB:　数据比特串－－＞最原始的编码数据RBSP:　原始字节序列载荷－－＞在SODB的后面填加了结尾比特（RBSP trailing bits　一个bit“1”）若干比特“0”,以便字节对齐。EBSP:　扩展字节序列载荷– >在RBSP基础上填加了仿校验字节（0X03）它的原因是：　在NALU加到Annexb上时，需要填加每组NALU之前的开始码 StartCodePref
RTP协议的基本封包格式
最新发布
gqd0757的博客
07-03 306
RTP协议封包格式非常灵活，允许根据应用的需求添加和扩展字段。这种灵活性使得RTP协议适用于各种实时通信场景。
h264编码的RFC3984传输实现
04-08
h264 over rtp传输的rfc3984实现， fu分包以及组包算法实现。
H264 RTP负载格式中文说明 —— H264 RTP Payload Format
08-23
这是在网上找的资料，是关于H264的RTP负载格式中文简单说明。整理了一下格式，便于阅读。对于刚涉及这方面研究的人，不妨先看看这个资料，再具体的去看相关的协议文档。
RTP封装h264
闲云野鹤 的专栏
04-09 884
文章部分借用网上搜索到的资料 网络抽象层单元类型 (NALU): NALU头由一个字节组成,它的语法如下:       +---------------+       |0|1|2|3|4|5|6|7|       +-+-+-+-+-+-+-+-+       |F|NRI|  Type   |       +---------------+ F: 1
H264关于RTP协议的实现
zhangfulin_hwatop的专栏
11-13 667
H264关于RTP协议的实现 对于H．264视频的实时传输应用来说，TCP的重传机制引入的时延和抖动是无法容忍的，因此我们采用UDP传输协议。但是UDP协议本身是面向无连接的，不能提供质量保证。而基于UDP之上的高层协议RTP／RTCP可以一起提供流量控制和拥塞控制服务。 TAG: H264  RTP  RFC3984   完整的C／S架构的基于RTP
h264的rtp包格式
小鱼儿的专栏
12-07 306
RFC6184定义的包类型如下： 这里我们只关心1-23，STAP-A及FU-A，其他类型可不关心，这是一个快速应用的时代； 对于单个NAL单元包，其包格式如下： 其NALU头与H264的NULU一致； ffmpeg中解析代码如下： 3. STAP-A聚合包格式示例如下： ffmpeg中解析代码如下： 4. 分片包FU-A格式如下： 其中，FU indicator 及 FU header定义如下： ffmpeg中解析代码如下： 典型的应用是，NALU未超过最大单元，则发送单..
H264与RTP
hyshucom
07-26 76
有关流媒体的项目中H264数据都是作为RTP的荷载来进行传输的。 但是作为RTP荷载可能存在这样的问题，比如一个NALU的大小超过了MTU必须做拆分后才能传输，还有就是一个NALU太小如果单独作为一个包发出去的话可能比较“浪费”。这样就产生了如下几种荷载格式： (1) 单个NAL单元包： 荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元类型,即在范围1到23之间（参照表二）。 ...
H.264 RTP payload 格式
10-19
《H.264 RTP payload 格式》是关于视频编码技术的重要文档，它详细阐述了如何在实时传输协议（RTP）中封装H.264编码的视频数据。H.264，全称ITU-T的G.729系列标准之一，是一种高效的视频压缩标准，广泛应用于网络...
H264 RTP 封包原理.pdf
10-15
总结来说，H264的RTP封装原理是将H.264编码的视频流通过NAL进行网络适应，然后利用RTP协议进行传输，确保视频数据在不同网络环境下的稳定和高效流动。这个过程涉及到了视频编码、网络适配和实时传输等多个技术层面，...
H265 RTP封装格式
03-05
### H265 RTP封装格式详解 #### 一、引言 H.265（也称为High Efficiency Video Coding，HEVC）是一种先进的视频压缩标准，由ITU-T和ISO/IEC联合制定，旨在提高视频编码效率并降低带宽需求。在传输过程中，H.265通常...
H264 RTP 发送和接收
05-18
H264 RTP 发送和接收,比较详细地介绍了用rtp协议发送h264码流的方法
基于RTP协议的H264流传输
06-23
基于JRTPLIB的h.264流文件传输，希望能对初学者有帮助
支持解析H264文件的封装类，可以获得每一帧数据
02-02
可以读取H264文件，并从中提取每一帧（是完整一帧，不是NAL）的数据，并能获得视频的分辨率。
使用RTP协议发送和接收H264的例子(支持解码、播放)
01-15
MFC实现的窗口程序，集成了发送和接收RTP包的功能，接收到的视频用FFmpeg解码并显示出来。该例子代码对应我博客上的一篇文章：https://blog.csdn.net/zhoubotong2012/article/details/86510032
h264 rtp打包 java版本
07-12
标题 "h264 rtp打包 java版本" 描述了一个使用Java编程语言将从文件读取的H264视频流进行RTP打包并发送的过程。在这个过程中，我们需要理解几个关键概念和技术： 1. **H264**：H264（也称为AVC，Advanced Video ...
recv_ps_data.zip_19A_h264 ps rtp封装_ps h264 rtp_rtp h264 ps_rtp
07-14
本主题聚焦于“recv_ps_data.zip_19A_h264 ps rtp封装 ps h264 rtp rtp h264 ps rtp”，这涉及到H264编码视频在RTP协议中的封装和解析过程。 H264，全称High Efficiency Video Coding（高效视频编码），是现代视频...
H264 RTP头分析
yuanzhenhai的专栏
06-30 2969
h264 RTP头解析流程 结合NALDecoder.c分析协议分析 ：每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前 12 个字节的含义是固定的，而负载则可以是音频或者视频数据。 一个活动顺序参数集在一个编码视频序列中保持不变,一个活动图像参数集在一个编码图像里保持不变。H.264 编码器必须根据H.264规范设置NRI值(subclause 7.4.1)当nal_unit_type 范围的是1到12. 特别是, H.264规范， 要求对于nal_unit
RTP发送H264
RobertBaker的专栏
04-09 3567
const uint8_t * FindNALHead(const uint8_t *lpStart, size_t nLength) { const uint8_t *lpBeg= lpStart + 0; const uint8_t *lpEnd= lpStart + nLength; uint32_t lValue = 0; for (; lpBeg != lpEnd; ++lpB
H.264视频的RTP负载格式
RTP负载格式是将H.264编码的视频数据封装在RTP包中的规范，它允许在不同网络环境下有效地传输视频流。 该RTP负载格式的关键特性包括： 1. **NALU打包**：H.264编码器生成的NALUs可以被合并到单个RTP包中，或者分散...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值