3

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

我在调整 jitter_buffer_common.h 中的 kMaxVideoDelayMs 值后重建了 Chromium。这产生了好坏参半的结果，包括在接收视频时产生不稳定的行为（断断续续）以及使 googPlisSent 随着时间的推移稳步上升。此外，当 kMaxVideoDelayMs 设置为低于某个阈值（大约 60 毫秒）时，googJitterBufferMs 和 googTargetDelayMs 会不规律地跳跃。将 kMaxVideoDelayMs 设置为 100 毫秒时，一切似乎都运行良好，但我想尽可能地减少整体延迟。

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

4

1 回答 1

0

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

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

于 2015-11-06T06:11:44.890 回答