Chrome中WebRTC RTP头扩展Playout-Delay不生效问题排查

环境信息 #

• 渲染服务器：UnityRenderStreaming 3.0.0-pre.4，基于WebRTC M107实现音视频推流
• 客户端：Chrome 111.0.5563.148

问题详情 #

在渲染服务器设置Playout-Delay {0, 0}（最大、最小延迟均为0），预期能降低Chrome的抖动缓冲延迟（jitterbufferdelay）至接近0ms，但实际查看WebRTC统计数据发现，该延迟与未设置参数时无变化。

已确认事项 #

• Chrome的SDP应答/Offer包含a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
• Wireshark捕获的RTP包中存在Playout-Delay数据

请问为何抖动缓冲延迟未降低？是否存在其他影响该行为的参数？

1. Chrome本身有抖动缓冲下限
   Chrome的WebRTC内核对抖动缓冲设了最低门槛，哪怕你把Playout-Delay设成0，它也不会真的把缓冲压到0。比如M107/M111这类版本，音频的最小缓冲大概在几十毫秒，视频也有类似硬限制——这是为了防止网络稍有波动就出现卡顿，属于浏览器层面的兜底逻辑。

2. Unity预览版插件可能存在参数传递bug
   你用的是UnityRenderStreaming 3.0.0-pre.4预览版，可能存在Playout-Delay参数没有正确传递到WebRTC底层的问题。可以查看插件源码，确认设置的{0,0}是否真正同步到了WebRTC的媒体轨道配置中。

3. 编解码流程自带固有延迟
   服务器端编码、Chrome端解码过程本身会产生固定延迟，比如H.264编码通常会缓存几帧再输出，这部分延迟会被计入jitterbufferdelay统计，但Playout-Delay参数无法控制这部分延迟。

4. 统计数据的定义差异要注意
   别混淆jitterbufferdelay和targetDelay：jitterbufferdelay是当前实际使用的缓冲延迟，而Playout-Delay是告诉Chrome的目标延迟范围。如果网络存在抖动，Chrome会优先保障播放流畅性，暂时忽略你设置的下限。可以查看targetDelay统计值，确认Chrome是否已接收0的设置——若targetDelay为0但jitterbufferdelay未下降，那就是网络波动或浏览器兜底限制导致的。

5. Chrome实验开关可能未完全开启
   虽然SDP中已包含Playout-Delay扩展，但Chrome可能需要开启特定实验开关才能让下限设置生效。打开chrome://flags搜索WebRTC Playout Delay Control相关选项，确认是否处于开启状态（M111版本大概率默认开启，但建议核实）。

6. 音视频同步机制的影响
   如果是音视频同步推流场景，WebRTC会自动调整视频播放延迟以对齐音频。此时即使设置视频的Playout-Delay为0，也会被音频的缓冲延迟拉高，导致整体jitterbufferdelay统计值无变化。可以单独推送视频流进行测试，观察延迟是否下降。

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