典型的Voximplant技术支持请求：“为什么两个Chrome之间的视频通话看起来比MS Edge和本地iOS应用程序之间的视频通话更好？” 同事通常会做出中立的回应-“因为编解码器”。 但是我们IT人员很好奇。 即使我不是在开发新的Skype-for-web，也要阅读“浏览器可以做什么”，以及如何将一个视频分成质量不同的多个流来充实世界，并为在吸烟室中讨论提供了新的话题。 成功地发表了来自狭窄圈子中广为人知的
Alex博士的文章（根据我所见，对“媒体引擎”一词有最好的解释），我们的一些经验，在“ Dial”中的两个晚上-以及为Habr改编的翻译正在等待削减！
编解码器和通道宽度
在谈论视频编解码器时，大多数情况下，他们会讨论所用通道的质量和宽度之间的平衡。 他们喜欢忽略处理器负载问题以及如何从技术上传输视频。 如果我们正在讨论已录制视频的编码，那是非常合理的。
毕竟，如果您已经完成了视频，则没有太大的区别，它将压缩几分钟，几小时甚至几天。 任何处理器和内存成本都是合理的，因为这是一次性投资，然后您可以将视频分发给数百万的用户。 最好的视频编解码器可以通过几遍压缩视频：
- Pass＃1：视频分为具有共同特征的部分：动作发生在相同的背景，快或慢的场景等上。
- 第2遍：收集编码的统计信息以及有关帧如何随时间变化的信息（为了获得此类信息，您需要几个帧）。
- 第3遍：每个部分均使用自己的编解码器设置以及第二步中获得的信息进行编码。
流是完全不同的事情。 在开始对视频进行编码之前，没有人会等到播客，流媒体或节目的结尾。 立即编码并发送。 依靠它并指示最小延迟变得最重要。
当使用物理媒体，DVD或蓝光光盘时，视频大小是固定的，编解码器要面对确保给定大小的最大质量的任务。 如果视频是通过网络分发的，则编解码器的任务是准备此类文件，以便在需要降低价格的情况下获得具有固定通道宽度的最大质量或具有固定质量的最小通道宽度。 在这种情况下，可以忽略网络延迟，并在客户端将其缓冲为所需的视频秒数。 但是对于流传输，并不需要特别固定大小或质量，编解码器具有不同的任务：不惜一切代价减少延迟。
最后，编解码器制造商长期以来只记住一种用例：在用户的计算机上，只能播放一个视频。 而且，几乎可以始终通过视频芯片的作用力对其进行解码。 然后是移动平台。 然后是WebRTC，以确保开发人员真正希望使用选择性转发单元服务器的最小延迟。
进行视频通话时使用编解码器与播放视频时的传统用法有很大不同，因此“正面”比较编解码器变得毫无意义。 在WebRTC初期比较VP8和H.264时，最热烈的讨论之一是编解码器设置：使用不可靠的网络使其“逼真”，或使视频质量达到最佳的“理想”。 那些“干净的编解码器比较”的斗士们严肃地认为，应该比较编解码器而不考虑数据包丢失，抖动和其他网络问题。
那么编解码器呢？
- H.264和VP8的视频质量和使用的通道宽度之比大致相同；
- H.265和VP9也大致对应，由于处理器负载增加了20％，因此与上一代编解码器相比平均显示出30％的更好结果；
- 新的AV1编解码器是VP10，daala和thor的爆炸性混合物，比上一代的编解码器好得多，也比以前的编解码器好。
现在令人惊讶的是：在视频通话和视频会议方面，每个人都不关心这些差异。 最重要的是编解码器如何与其他基础架构一起组成团队。 开发人员担心所谓的新
媒体引擎 ：浏览器或移动应用程序如何捕获视频，对其进行编码/解码，将其分解为RTP数据包并处理网络问题（还记得我们
以前的文章吗？引擎-译者注）。 如果编码器不能在通道宽度急剧减小的情况下工作，或者不能稳定地每秒保持20帧，如果解码器在丢失一个网络数据包的情况下不能工作，那么编解码器对视频的压缩效果如何？ 显而易见，为什么Google赞助
斯坦福大学关于编解码器和网络之间最佳交互的
研究 。 这是视频通信的未来。
编解码器和媒体引擎：一切都很复杂
视频通话和视频会议的任务
几乎与传统媒体相同。 只有优先级
完全不同：
- 每秒需要30帧（编解码器速度）。
- 需要每秒30帧的交互性（最小延迟）。
参与者之间也有互联网，我们只能猜测其质量。 通常情况更糟。 因此：
- 当另一个访问者来共同工作时，您需要很好地体验通道宽度的细微变化。
- 当此访客开始下载种子时，您至少需要以某种方式体验到频道宽度的巨大变化。
- 您需要担心抖动（接收到的数据包之间的随机延迟，由于它们不仅会延迟，而且会以错误的发送顺序到达）。
- 需要担心数据包丢失。
3.1。 媒体引擎的主要任务
“每秒需要30帧”是什么意思？ 这意味着媒体引擎有33毫秒的时间来捕获来自摄像机的视频，来自麦克风的声音，使用编解码器对其进行压缩，将其拆分为RTP数据包，保护传输的数据（SRTP = RTP + AES）并通过网络发送（UDP或TCP） ，在大多数情况下为UDP）。 所有这些都在发送方。 在接收端-以相反的顺序重复。 由于编码通常比解码困难，因此发送方的时间更难。
在技术方面，可以“延迟”达到“每秒30帧”的目标。 延迟越大，越容易实现目标：如果在发送端一次编码多个帧，而不是一次编码，则可以显着节省通道宽度（编解码器通过分析所有帧之间的变化来更好地压缩多个帧，不仅在当前和以前之间）。 同时，从摄像机接收视频流与通过网络发送之间的延迟与缓冲的帧数成比例地增加，加上压缩由于其他计算而变慢。 许多站点使用此技巧来声明视频通话参与者之间在发送和接收网络数据包之间的响应时间。 编码和解码的延迟，它们是无声的。
为了使视频通话看起来像个人通信，通信服务的创建者拒绝所有可能造成延迟的设置和编解码器配置文件。 事实证明，这种现代编解码器已退化为逐帧压缩。 首先，这种情况引起了编解码器开发人员的拒绝和批评。 但是时代已经变了，现在，现代编解码器除了传统的预设“最小大小”和“最大质量”外，还增加了一组“实时”设置。 同时，“屏幕共享”也适用于视频通话（它具有其自身的特性-高分辨率，图片稍有变化，需要无损压缩，否则文本会浮动）。
3.2。 媒体引擎和公共网络
通道宽度的微小变化
以前，编解码器无法更改比特率：在压缩开始时，他们将目标比特率作为设置，然后每分钟发布固定数量的兆字节视频。 在过去，视频通话和视频会议是许多本地网络和冗余带宽。 并且在出现问题的情况下，将调用管理员的姓名，该管理员将通道宽度的预留位置固定在tsiska上。
第一个进化变化是“自适应比特率”技术。 编解码器具有影响比特率的许多设置：视频分辨率，每秒fps从30帧略微降低到25帧，视频信号的量化。 此列表中的最后一个是颜色之间过渡的“粗化”，人眼几乎看不到它们的细微变化。 通常，自适应比特率的主要“调整”是精确量化。 媒体引擎告诉编解码器有关通道宽度的信息。
通道宽度变化大
自适应比特率机制可帮助媒体引擎以较小的通道宽度变化继续广播视频。 但是，如果您的同事开始下载种子，并且可用频道下降了两三倍，那么自适应比特率将无济于事。 降低分辨率和帧速率将有所帮助。 后者是可取的，因为我们的眼睛对每秒帧数的敏感度小于对视频分辨率的敏感度。 通常，编解码器开始跳过一两个帧，将帧速率从30降低到15，甚至降低到10。
重要细节：媒体引擎将在发送方跳过帧。 如果我们有一个可以召开多个会议的视频会议或广播，而发送方没有网络问题，那么一个“弱链接”将恶化所有与会者的视频质量。 在这种情况下，一串联播会有所帮助（发送方立即发送几个质量不同的视频流）和SFU（选择性转发单元，服务器为每个参加者召开视频会议或广播所需质量的流）。 一些编解码器具有创建多个同时广播流的能力，这些SVC可以相互补充：为通道最弱的客户端提供最低质量的流，为通道更好的客户端提供相同的流以及第一次“升级”，为通道更好的客户端提供已经有两个“升级”流，依此类推。 与编码多个完整的视频流相比，此方法使您可以不将相同的数据传输到多个流，并且可以节省大约20％的流量。 这也简化了服务器的操作-无需切换流，足以不将带有“升级”的数据包传输到客户端。 但是，任何编解码器都可以用于联播，这是媒体引擎和RTP数据包组织的功能，而不是编解码器。
抖动和丢包
损失是最难处理的。 抖动要简单一些-只需在接收端建立一个缓冲区，以收集延迟和混乱的数据包。 缓冲区不要太大，否则您可以打破实时性，成为YouTube视频的缓冲对象。
数据包丢失通常是通过转发（RTX）来解决的。 如果发送方与SFU的通信良好，则服务器可以请求丢失的数据包，对其进行检索，仍然可以满足33毫秒的要求。 如果网络连接不可靠（丢包率超过0.01％），则我们需要复杂的丢包工作算法，例如
FEC 。
到目前为止，最好的解决方案是使用SVC编解码器。 在这种情况下，要接收至少一些视频，只需要具有最低质量流的“参考”数据包，这些数据包就更少了，因此重发它们很容易，即使在网络非常差（数据包丢失超过1％）的情况下也足以“生存”。 如果Simulcast + SFU允许您处理信道沉陷，那么Simulcast借助SVC编解码器+ SFU可以解决信道宽度和丢失数据包的问题。
浏览器现在支持什么
Firefox和Safari使用Google的Media Engine并不时更新libwebrtc。 它们的执行频率比Chrome（每6周发布一个新版本）的频率要低得多。 它们有时会不时地开始落后，但随后又重新同步。 除了在Safari中支持VP8编解码器之外。 甚至都不问。
在使用kat之前，有一张表可以对谁支持什么进行了完整的比较，但是总的来说，一切都很简单。 边缘通常被所有人忽略。 选择是在支持Safari的移动版本还是获得良好的视频质量之间。 iOS Safari仅支持H.264视频编解码器，而libwebrtc仅允许使用VP8编解码器（具有不同帧速率的不同流）和VP9（支持SVC）进行联播。 但是您可以通过创建本机应用程序在iOS上阅读和使用libwebrtc。 然后，通过联播，一切都会好起来的，并且用户可以通过不稳定的Internet连接获得最高质量的视频。 一些例子：
- Highfive-具有H.264联播（libwebrtc）和杜比声音编解码器的Electron（Chromium）桌面应用程序；
- Attlasian-客户端在React Native和libwebrtc上进行联播的有趣解决方案；
- Symphony –在那里支持台式机的Electron，移动设备的React Native和联播，以及与银行想要的兼容的其他安全功能；
- Tokbox-移动SDK中具有联播功能的VP8，请在libwebrtc中使用libvpx的修补版本。
未来
已经很清楚，Safari中将没有VP8和VP9（不同于Edge，VP8支持）。
尽管苹果公司支持将H.265包含在WebRTC中，但最近的新闻和许多间接迹象表明，AV1是“下一件大事”。 与本文的其余部分不同，这是我个人的看法。 数据传输AV1的规范已经准备就绪，但编解码器仍在工作中。 现在，编码器的参考实现显示每秒可悲的0.3帧。 播放预压缩的内容时这不是问题，但尚不适用于实时通信。 同时，您可以
尝试在Firefox中播放AV1视频，尽管这与RTC无关。 bitmovin团队的实施，该团队开发了MPEG-DASH，并获得了3,000万美元的投资，用于创建用于视频的下一代基础架构。