H264 流解码器如何决定 H264 编码器提供哪种类型的流答案

【问题标题】：How does a H264 stream decoder decides which type of stream is being fed by H264 encoderH264 流解码器如何决定 H264 编码器提供哪种类型的流
【发布时间】：2015-12-07 17:52:17
【问题描述】：

ITU-T H264 文档支持或至少推荐两种类型的流类型，即 RTP 数据包和附件 B（原始字节序列）。

我的问题是，假设编码器能够以两种格式发送流式数据，并且可以在流式传输时的任何时间点在它们中的任何一个之间切换（如果不是这种情况，则正确），如何以及何时H264解码器是否知道它需要根据RTP格式或附件B（即原始字节序列数据）解析数据。

是否有任何标准协议或机制可以做到这一点。

如果出现数据包丢失并且编码器切换其流式传输数据的方式（即从 RTP 到附件 B 或反之亦然）会发生什么情况，此时解码器可能仍假定数据以旧格式流式传输。

请澄清以上内容。

【问题讨论】：

混合数据格式是在自找麻烦。如果有数据包丢失，最好的错误保护是重新发送数据包或忽略损坏的数据并在可用时跳转到下一个数据包数据（查看者看到瞬间图片冻结或跳帧）
Annex B 通常存在于存储的文件（如 MP4）中，而 RTP 用于实时广播。只是说在中途随时切换反之亦然是多么尴尬。这些格式用于解决不同的问题
@VC.One 让我们假设以下情况，我也不确定为什么不能以 RBSP 格式发送实时流。场景：编码器正在发送 RTP 数据包，发生丢失并且 RTP 流在这里重新开始，丢失的数据包被解码器忽略并继续后续数据包（但解码器不需要与编码器同步什么类型的流正在发送 RTP 或 RBSP）。而且我不确定编码器是否有任何限制，不能在丢失或运行时切换流类型。
你把它弄得太复杂了。解码器的功能只需要 h.264 数据，它们会给出相关的像素来显示。其他一切都只是为了“包含”或“传输”数据。在提取 h.264 以传递给解码器之前，切换流类型（= 编写更多代码来处理字节结构的突然差异）并没有什么巧妙的好处。无需将解码器与编码器同步。如果我今天对视频进行编码，一周后加载（解码）文件时它如何同步？
@VC.One 我同意在播放录制的流时不需要同步，但在直播的情况下同步问题仍然存在。还要考虑附件 B 的情况，即编码器正在流式传输 RBSP 流，而解码器正在解码相同的内容，突然丢包，解码器设备关闭并重新启动。现在在这些时间之间，编码器仍在流式传输 RBSP，现在解码器将如何知道流类型是什么（RBSP 或 RTP）。解码器如何自我同步以及如何知道一帧何时开始

标签： video-streaming h.264 video-capture video-processing rtp

【解决方案1】：

通常，在大多数情况下，H264 编码器以 NAL（网络抽象层）形式生成数据包。每个 NALU（NAL Unit）由一个 NAL-Header 和 RBSP（Raw Byte Sequence Payload）组成。与 H264 编码器类似，大多数解码器都能够理解 NALU（不是真正的 RTP）。 NAL 标头大小为 1 字节。

NAL 单元有 2 种 RTP 打包方法。在一种方法中，允许对 NAL 进行分段，而另一种方法不允许对 NALU 进行分段。在这两种方法中，RTP 标头后跟 NALU。假设编码器和解码器都以理解 RTP 标头的方式实现，那么它们应该首先解析标头，因为标头的大小始终是固定的。然后，检查 RTP 和/或 NAL 标头以相应地对其进行处理以进行进一步解析。

总而言之，RTP 和 NAL 只是标头，它是关于在解码实际视频数据之前解析 RTP 或 NAL 标头的方法。最好用信号通知将数据流式传输到解码器的模式（RTP 或 NAL）。这使得解码器的生活很容易避免错误处理任何数据包的错误。

在丢包的情况下，一切都与解码器弹性方法有关。没有针对数据包 (NALU) 丢失的标准化方法。一些解码器确实为丢包场景提供了错误隐藏。

添加了更多详细信息：

您需要在解码器端拥有两个标头（RTP 和 NAL）解析实现。如上所述，最好有一个信令机制来指示数据包被发送到解码器的模式。由于 NAL 标头是给定数据包中的子集（存在于 RTP 和 NAL 中），因此您最好先搜索 NAL 起始代码。一旦解码器在数据包中找到起始码，检查直到该点消耗的字节数 (x)。如果 x 大于 RTP 标头大小，则从数据包的开头以 RTP 模式开始解析。如果 RTP 解析顺利（通过根据手头的数据验证一些 RTP 字段），解码器可以断定在 RTP 模式下接收到数据包。以上方法适用于非分片RTP打包方式。

【讨论】：

ARK 里面提到的RFC6184打包方法我理解，但是我的问题不一样。问题是解码器如何得出编码器以数据包模式而不是 RBSP 格式发送 NALU 的结论。第二个问题也与帧或数据包丢失有关。假设 RTP 数据包丢失或在中途发生了丢弃，现在解码器如何知道它仍然需要将传入数据解析为 RTP 数据包。另外，如果编码器以 RBSP 格式发送数据，现在一些字节丢失了，解码器现在如何从字节序列中读取下一帧
@Krishna，我在答案中添加了更多细节。
ARK 请考虑附件 B 的情况，即编码器正在流式传输 RBSP 流，而解码器正在解码相同的流，突然丢包，解码器设备关闭并自行重启。现在在这些时间之间，编码器仍在流式传输 RBSP，现在解码器将如何知道流类型是什么（RBSP 或 RTP）。在这里，当这种丢失发生时，0x000001 字节流的开始丢失并且您在中途接收数据包。现在你如何确定下一个收到的数据包是 RBSP 还是 RFC6184 兼容的。
ARK ：请查看我早期的 cmets 在与丢失数据包相关的问题下，其中包含指示 RBSP 数据开始的字节。