javascript - WebRTC - 删除/减少共享视频流的设备之间的延迟？

Question

很抱歉没有发布任何代码，但我正在尝试了解更多关于延迟和 webRTC 的信息，消除两个或多个设备之间延迟的最佳方法是什么共享视频流?

或者，无论如何，尽可能减少延迟？

考虑到这一点，我想象只是将设备的时钟设置为同一时间，从而延迟来自服务器的请求，这是真正的把戏吗？

Answer 1

延迟是源(麦克风、摄像头)和输出(扬声器、屏幕)之间路径上步数的函数。

更改时钟对延迟的影响为零。

您的延误包括:

• 设备内部延迟——等待屏幕垂直同步等……；这里没什么可做的
• 设备接口(interface)延迟 - 较短的电缆会为您节省一些时间，但无法衡量
• 软件延迟 - 您的操作系统和浏览器；你可能可以在这里做一些事情，但你可能不想，相信你的浏览器制造商正在做他们能做的事情
• 编码延迟 - 更快的处理器在这里有一点帮助，但最大的问题是对于音频之类的事情，编码器必须等待一定数量的音频积累才能开始编码；默认情况下，这是 20ms，所以不多；最终，您将能够为 Opus 请求更短的 ptime(控件的名称)，但现在还处于早期阶段
• 解码延迟 - 同样，更快的处理器会有所帮助，但没什么可做的
• 抖动缓冲延迟 - 音频尤其需要在接收器处有一点额外延迟，这样任何网络抖动(数据包传输速率的波动)都不会导致音频中断；这通常不在您的控制范围内，但这并不意味着它完全不可能
• 重新同步延迟 - 当您播放同步的音频和视频时，如果一个因任何原因延迟，另一个的播放可能会延迟，以便两个可以一起播放；这应该相当小，并且可能超出您的控制范围
• 网络延迟 - 这是您可以提供帮助的地方，可能很多，具体取决于您的网络配置

当涉及到两个对等点之间的距离时，您无法改变物理情况，但是有很多网络特征可以改变实际延迟:

• 直接路径 - 如果出于任何原因，您正在使用中继服务器，那么您的延迟将会受到影响，可能会很严重，因为每个数据包都不会直接传输，而是绕过中继服务器
• 管道大小 - 尝试将高分辨率视频塞入小管道可以奏效，但将大帧内帧塞入小管道可能会增加一些额外的延迟
• TCP - 如果禁用 UDP，回退到 TCP 会对延迟产生非常严重的影响，这主要是由于数据包丢失的特殊暴露，这需要重新传输并导致后续数据包延迟直到重新传输完成(这是称为线头阻塞)；这也可能发生在某些不正当的 NAT 场景中，即使理论上启用了 UDP，尽管这很可能会导致使用中继服务器
• 更大的网络问题 - 也许您的对等点位于不同的 ISP 上，而这些 ISP 的对等安排很差，因此数据包在对等点之间采用次优路由； traceroute 可能会帮助您确定事情的发展方向
• 拥塞——也许你的网络有些拥塞；拥塞往往会导致额外的延迟，特别是当它是由 TCP 引起时，因为 TCP 往往会填满路由器中的尾丢弃队列，迫使您的数据包等待额外的时间；如果您正在使用数据通道，您也可能会导致自拥塞，那里的拥塞控制算法与 TCP 默认使用的算法相同，这对实时延迟不利

我敢肯定这不是一个完整的分类法，但这应该可以让您入门。