ITU-T H264文档支持或至少推荐两种类型的流类型，即RTP数据包和附件B（原始字节序列）。
我的问题是，让我们假设编码器能够以两种格式发送流数据，并且可以在流式传输的任何时间点切换它们中的任何一个（如果不是这样，则更正），如何以及何时H264解码器是否知道它需要根据RTP格式或附件B即原始字节序列数据来解析数据。
是否有任何标准协议或机制可以做到这一点。
如果数据包丢失并且编码器切换流数据的方式会发生什么情况，例如从RTP到附件B，反之亦然，这里解码器可能仍假设数据以旧格式流式传输。
请澄清以上内容。
答案 0 :(得分：4)
通常，大多数情况下，H264编码器以NAL（Netwrok抽象层）形式生成数据包。每个NALU（NAL单元）由NAL-Header和RBSP（原始字节序列有效载荷）组成。与H264编码器类似，大多数解码器都能够理解NALU（不是真正的RTP）。 NAL头的大小为1字节。
NAL单元有2种RTP分组方法。在一种方法中，允许NAL分段，并且其他方法不允许分段NALU。在这两种方法中，RTP标头后跟NALU。假设编码器和解码器都以一种理解RTP头的方式实现，那么它们应首先解析头，因为头总是固定大小。然后，检查RTP和/或NAL标头以相应地对其进行进一步解析。
有关详细信息，请参阅RFC 6184 - RTP Payload Format for H.264 Video
总之，RTP和NAL只是标题，它是在解码实际视频数据之前解析RTP或NAL标头的方法。最好发信号通知数据流到解码器的模式（RTP或NAL）。这使得解码器的生命很容易避免错误地处理任何数据包。
在数据包丢失的情况下，它完全是关于解码器弹性方法。没有标准化的数据包（NALU）丢失方法。一些解码器确实为丢包情况提供了错误隐藏。
更多细节已添加：
您需要在解码器端同时具有标头（RTP和NAL）解析实现。如上所述，最好具有信令机制来指示分组被发送到解码器的模式。由于NAL头是给定数据包中的子集（存在于RTP和NAL中），因此最好先搜索NAL起始码。一旦解码器在数据包中找到起始码，检查直到该点消耗的字节数（x）。如果x大于RTP头大小，则从数据包的开头以RTP模式开始解析。如果RTP解析顺利（通过针对手中的数据验证一些RTP字段），解码器可以断定在RTP模式下接收到数据包。上述方法适用于非分段RTP分组方法。