是否可以禁用WebRTC中的抖动缓冲区（Chrome / Chromium）

Question

我正在尽可能地为远程机器控制应用程序减少Chromium WebRTC视频延迟。由于发送和接收PC通过以太网（交叉电缆）直接连接，我猜测接收缓冲可能不是必需的，因为不应该有延迟，无序或丢失的数据包。

我在调整jitter_buffer_common.h中的kMaxVideoDelayMs值后重建了Chromium。这带来了不同的结果，包括通过接收视频（波涛汹涌）创建不稳定的行为以及使googPlisSent随着时间的推移稳步上升。此外，当kMaxVideoDelayMs设置为低于某个阈值（大约60ms）时，googJitterBufferMs和googTargetDelayMs会不规律地跳转。 kMaxVideoDelayM设置为100ms，一切似乎都能正常工作，但我想尝试尽可能减少整体延迟。

我想知道是否可以完全禁用或绕过接收抖动缓冲区，因为它似乎可以减少在发送PC上捕获视频和在接收PC上显示它之间的整体延迟。

Answer 1

您仍然需要一个抖动缓冲区来存储数据包，直到您拥有整个帧（并执行其他与抖动缓冲区挂起的相关处理）。音频抖动缓冲器通常可以有效地运行，并控制音频/视频何时显示。这一切都在NetEq深处，可能无法禁用。

如果您将音频和视频作为单独的流（未同步或没有音频）运行，那么视频应该已经尽可能快地运行，但如果有延迟，则是由于操作系统调度，并且可能还有在DeliverFrame代码中有一定量的调步延迟（或者更确切地说是最终调用DeliverFrame的代码）。