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

Question

对于没有发布任何代码，但正在学习关于延迟和WebRTC的人，什么是消除两个或多个共享视频流设备之间延迟的最佳方法？

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

考虑到这一点，我想到了只需将设备时钟设置为相同的时间即可延迟来自服务器的请求，这是真正的诀窍吗？

- itsme

---

服务器和客户端之间的延迟(latency)不是无法消除吗？您想要减少不同客户端之间的偏移量(offset)并对它们进行同步(synchronize)吗？ - Bergi

@Bergi 是的，将所有同步客户端一起使它们能够处于真实/相当真实的实时状态。 - itsme

你有一些有用的想法吗？我的问题和你的类似。链接是在这里输入链接描述 - mustconfident

@mustconfident 不是的 :( - itsme

Answer 1

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

更改时钟对延迟没有任何影响。

您可能会遇到以下延迟:

• 设备内部延迟-等待屏幕垂直同步等；在这里不需要做太多事情
• 设备接口延迟-较短的电缆可以节省一些时间，但不能量化
• 软件延迟-您的操作系统和浏览器；您可能可以在此处做些什么，但您可能不想信任您的浏览器制造商正在尽力而为
• 编码延迟-更快的处理器在这里有所帮助，但最大的问题是对于像音频这样的东西，编码器必须等待一定量的音频积累才能开始编码；默认情况下，这是20ms，因此不多；最终，您将能够请求Opus的更短ptimes（控件的称呼），但现在还为时过早
• 解码延迟-同样，更快的处理器有所帮助，但可以做的事情不多
• 抖动缓冲延迟-特别是音频需要接收器稍微多一点的延迟，以便任何网络抖动（传递数据包的速度波动）不会导致音频中断；这通常超出您的控制范围，但这并不意味着完全不可能
• 重新同步延迟-当您播放同步音频和视频时，如果其中一个由于任何原因被延迟，另一个的播放可能会被延迟，以便两者可以同时播放；这应该相当小，并且很可能超出您的控制范围
• 网络延迟-这就是您可以帮助的地方，在很大程度上取决于您的网络配置

在两个对等点之间的距离方面，您无法改变情况的物理性质，但许多网络特性可以改变实际延迟：

• 直接路径-如果由于任何原因，您使用了中继服务器，则延迟可能会受到损害，因为每个数据包都不是直接传输，而是通过中继服务器绕道而行

管道大小 - 尝试将高分辨率视频塞入小型管道可能有效，但将大的关键帧压缩到小型管道中可能会增加额外的延迟。

TCP - 如果UDP被禁用，退回到TCP可能会对延迟产生相当严重的影响，主要是由于对数据包丢失的特别敏感，需要重传并导致随后的数据包等待重传完成（这称为头部阻塞）; 即使在理论上启用了UDP，在某些扭曲的NAT情况下也可能发生这种情况，尽管最可能的结果是使用转发服务器。

更大的网络问题 - 可能你和你的同行使用不同的ISP，并且这些ISP之间的对等安排很差，因此数据包在同行之间走了一条次优路线。traceroute可以帮助您确定事物的去向。

拥堵 - 可能您的网络存在一些拥堵；拥堵倾向于导致额外的延迟，特别是当它是由TCP引起时，因为TCP倾向于填满路由器中的tail-drop队列，迫使您的数据包等待更长时间；如果您使用数据通道，则可能会引起自我拥堵，那里的拥堵控制算法与TCP默认使用的算法相同，这对实时延迟非常不利。

我确定这不是一个完整的分类法，但这应该可以给你一个开始。

- Martin Thomson

Answer 2

除了使用网络速度更快且延迟更低的更好网络之外，我认为你无法做些什么来提高延迟。如果您在同一网络或WiFi上，则应该几乎没有延迟。

我认为，设备处理能力较差时延迟也会增加，因此它们无法快速解码视频，但是你不必担心它，因为所有操作都在浏览器中进行。

你可以尝试的方法 是尝试使用不同的编解码器。因此，在发送SDP之前，您需要操纵m = audio或m = video行中的编解码器顺序或删除编解码器。(但选择视频编解码器并不多，只有VP8)

您可以在chrome附带的工具中查看编解码器和网络性能：
chrome://webrtc-internals/
只需在URL栏中输入即可。

- JustGoscha