WebRTC接收H264关键帧问题：libdatachannel无法快速获取关键帧

我正在使用libdatachannel进行WebRTC的学习与实验，编写了将RTP包解析为NALU的代码，并对接发送H264视频的可靠服务器测试。

遇到的核心问题：

• 仅能接收到类型为1（拆分为多个FU-A）的NALU，偶尔会收到包含嵌入式SPS和PPS的类型24的NALU。
• 由于服务器不会自动向新连接的客户端发送关键帧（NALU type 5），导致无法启动解码渲染流程。
• 尝试通过代码主动请求关键帧，虽能收到但延迟不可接受；但Chrome等浏览器客户端却能快速正常播放该流。

想明确的几个问题：

1. 是否浏览器也存在延迟只是我感知不到？
2. 关键帧的发送机制是怎样的？
3. 是否需要客户端主动请求关键帧？若需要，请求的合理间隔是多少？

浏览器的延迟感知问题 #

浏览器确实会等待关键帧，但这个等待过程被优化到了几乎不可感知的程度：

• 浏览器的WebRTC栈在媒体连接建立后，会立即发送关键帧请求；
• 多数专业流媒体服务器会缓存最近生成的关键帧，收到请求后直接下发，不会等待下一个自然生成的关键帧（自然关键帧间隔通常在1-5秒，这正是你手动请求延迟高的核心原因）。
  两者结合，浏览器的等待时间通常在几百毫秒内，自然不会被感知到。

关键帧的发送机制 #

关键帧发送分为两种核心场景：

• 主动广播：服务器按固定间隔（一般1-5秒）生成关键帧并向所有客户端广播，用于同步新接入的客户端，或纠正长时间丢包导致的解码错误。
• 被动响应：客户端发送RTCP的PLI（Packet Loss Indication，丢包指示）或FIR（Full Intra Request，全帧内请求）报文触发关键帧请求，服务器收到后立即生成关键帧，或下发缓存的最近关键帧。
  你的服务器显然没有开启“新连接自动推送关键帧”的逻辑，也没有缓存关键帧，导致你手动请求时只能等待下一个自然生成的关键帧，因此延迟极高。

客户端关键帧请求的必要性与合理策略 #

客户端必须主动请求关键帧，这是WebRTC视频流初始化的标准流程：

• 连接初始化阶段：媒体通道建立成功后，立即发送1次PLI请求；如果300ms内未收到关键帧，补发1次FIR请求（FIR优先级更高，服务器会优先响应）。
• 日常播放阶段：仅当出现解码错误（如画面花屏、无法解码连续帧）时，再触发PLI请求，无需定时轮询——频繁请求会浪费带宽，还可能导致服务器生成过多关键帧，影响整体流的稳定性。

内容的提问来源于stack exchange，提问作者Kostya Vasilyev