您需要决定什么对您更重要——质量还是延迟，试图对两者进行优化注定会惨败。
我问那些想用WebRTC做直播服务的人的第一件事是：
你说的直播是什么意思？
这是一个基本问题，也是一个关键问题。
如果你在谷歌上搜索，你会看到供应商说直播的良好延迟是低于15秒。这可能是好的，但如果你正在看一场足球比赛的直播，而你的邻居比你早15秒看到了进球，他们在大喊大叫，这就很糟糕了。
我喜欢使用上图来显示不同协议的延迟差异。
WebRTC 让所有其他基于标准的协议望尘莫及。它是唯一真正的毫秒级延迟流媒体协议。这并不意味着它更优越——只是它针对延迟进行了优化。为了做到这一点，它牺牲了质量。
如何？
通过不重传或缓冲。
对于所有其他协议，您大多将通过 HTTPS 或 TCP 运行。而所有其他协议都严重依赖重传以获得完整的媒体流。原因如下：
- 网络很挑剔，在大多数情况下，这意味着您需要处理丢包问题；
- 您通过 Internet 流式传输媒体文件，在接收端，该文件的某些部分将会丢失——在传输过程中丢失；
- 所以你通过重传机制来管理它。最简单的方法是依靠HTTPS——浏览器使用的主要传输协议；
- HTTPS 依靠 TCP 提供数据传输的可靠性，而这又是通过重新传输丢失的数据包来完成的；
- 重传需要时间，这意味着要增加缓冲机制，为其工作腾出空间，提供流畅的观看体验。那个时间是我们看到的延迟，范围从 2 秒到 30 秒或更长时间。
WebRTC来自实时的、互动的、对话的领域。在那里，即使是一秒钟的延迟也是太长的等待–它破坏了对话的体验。因此，在WebRTC中，处理数据包丢失的主要方法不是重传，而是掩盖。WebRTC所做的是，它试图掩盖数据包的损失，并通过提供一个微调的带宽估计机制来确保尽可能少的损失。
查看 WebRTC 本身，它包含一个抖动缓冲区实现。抖动缓冲器负责延迟传入媒体的播放，这样做是为了帮助解决网络抖动，提供更流畅的播放。它还用于实现传入音频和视频流之间的同步。您可以通过指示它不要延迟播放来在某种程度上控制它。这将再次损害质量并改善延迟。
你看，你想要的延迟越低，你需要处理的技术难题就越大，以保持高质量。这反过来意味着，无论何时您想要减少延迟，您都将付出复杂性和交付质量的代价。不管怎样，这都要做出一个选择。
原文链接：https://bloggeek.me/media-delivery-optimize-for-quality-or-latency/
系列阅读
WebRTC 是一项技术而非解决方案【WebRTC认知篇1】
WebRTC 是一场马拉松，而不是短跑【WebRTC认知篇2】
WebRTC 减少了通信障碍并增加了创新【WebRTC认知篇3】
本文为原创稿件，版权归作者所有，如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/14556.html
