Video streaming H264流解码器如何决定H264编码器提供的流的类型

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

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

是否有任何标准的协议或机制来做到这一点

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

---

请澄清以上内容。

通常，在大多数情况下，H264编码器以NAL（Netwrok抽象层）形式生成数据包。每个NALU（NAL单元）由NAL报头和RBSP（原始字节序列有效负载）组成。与H264编码器类似，大多数解码器能够理解NALU（不是真正的RTP）。NAL标头的大小为1字节

NAL装置有两种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分组方法。

通常，H264编码器以NAL（Netwrok抽象层）形式生成数据包。每个NALU（NAL单元）由NAL报头和RBSP（原始字节序列有效负载）组成。与H264编码器类似，大多数解码器能够理解NALU（不是真正的RTP）。NAL标头的大小为1字节

NAL装置有两种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打包方法。

混合数据格式会带来麻烦。。如果出现数据包丢失，最好的错误保护是重新发送数据包或忽略损坏的数据，并跳转到下一个数据包（如果可用）（观众看到瞬间的图片冻结或帧跳转），附件B通常位于存储文件（如MP4）中，RTP用于实时广播。我只是想说，在中游的任何时候，如果换成中游的话，那该有多好。这些格式用于解决不同的问题problems@VC.One让我们假设以下场景，我也不确定为什么不能在RBSP foramat中发送实时流媒体。场景：编码器正在发送RTP数据包，发生丢失，RTP流再次开始。解码器将忽略丢失的数据包，并继续发送后续数据包（但解码器不需要这样做）