@qinyun 2018-04-17T16:39:56.000000Z 字数 2095 阅读 1957

Salsify：来自斯坦福的下一代RTC技术

未分类

Salsify是斯坦福研究的新型实时视频系统，它可协同控制视频编解码器和网络传输协议，在质量方面和延迟方面优于目前的实时视频系统。

项目背景

当前，实时视频系统如Skype、Facetime、WebRTC是由两个独立的组件构建的，一个是压缩视频的“视频编解码器”，另一个是网络“传输协议”，它根据数据传输速度来传输数据包，并避免网络过载。

多年来，视频编解码器和传输协议经过不同公司进行设计与构建，然后整合到诸如Skype、FaceTime等应用程序中。

然而，每个组件都有自己的控制回路，传输协议里有一个“拥塞控制”，它可以在发生拥塞时控制进入网络的数据量，而编解码器有自己的“速率控制”算法，并根据传输协议提供的信息进行视频压缩。传输协议必须和编解码器一同工作，当传输协议和编解码器不同步或网络条件不稳定时，就容易发生延迟现象或故障。

而Salsify是在单个回路中协同逐帧控制压缩和逐包控制传输，这可以让视频流根据网络的变化进行调整，避免延迟。

技术解读

当前的视频编码器不能准确预测单个视频帧的压缩大小，相反，编解码器总是试图控制几个帧的“比特率”（例如通过VBV约束）。如果编码器产生的帧与传输协议认为网络可以容纳的帧相比太大，应用程序通常会传输它，之后，它认为这可能会引起拥塞，那么应用程序可能会暂停将数据输入视频编码器，以缓解拥塞。

但这不是一个很好的方案，因为网络仍然拥塞。更好的方法应该是，如果编码器产生的压缩帧太大，系统应该提醒编码器重新试一次，不是通过降低质量对相同的帧进行重新编码，而是应该从摄像机中取出一个新帧，并进行编码，质量设置为不会使网络拥塞的压缩帧。实际上，只有在不会引起丢包和延迟的情况下才发送帧，而不应该固定帧的发送频率。

Salsify纯功能的视频编解码器就能实现这一点。它的视频编解码器与Google VP8格式100％兼容，编码和解码是纯功能性的，没有副作用，同时展现解码器的帧间“状态”。这将允许Salsify编码器相对于任意解码器状态压缩一帧，允许应用程序安全地跳过来自编码器输出的帧，而不仅仅是输入的帧。

Salsify的编解码器保证发送者不会在网络拥塞时发送帧（必要时会丢弃已经编码的帧），不固定帧的发送速率。它还允许编解码器生成更接近可用网络容量的帧，生成每个帧的两个版本：其中一个质量略高于先前的成功案例，另一个质量略低。应用程序在查看每个选项的实际压缩大小后，从这些选项中选择（或不选）。

Salsify压缩视频的格式是谷歌的VP8，之后被VP9和H.265 取代。Salsify的纯功能VP8编码器/解码器是去年用于ExCamera的一个修改过的版本，它的优点是允许我们将视频编码细分为小线程（小于关键帧之间的间隔），并且可以并行处理数千AWS Lambda上的线程。今年，Salsify可以探索视频编解码器的执行路径。Salsify的拥塞控制方案基于Sprout-EWMA，后者又基于数据包对（ packet-pair ）的早期工作和可用带宽的包列（ packet-train）估计。Salsify的损失恢复策略与Mosh的 “p-retransmissions” 相关。

综上，Salsify创新体现在新的组合方式——编解码器速率控制和传输拥塞控制，以及使用功能性视频编解码器，并仅在网络可以容纳它们时才发送编码帧。

性能对比

研究人员将Salsify与微软的Skype、Google Google Hangouts、苹果的FaceTime以及Google浏览器中的Internte 标准WebRTC协议进行测试，就平均而言，Salsify在延迟上仅是后者平均值的四分之一，图片质量至少提高了60%，

测试结果如下：

关于未来

Salsify的技术团队坦言，他们很希望Salsify能够融入行业中，并愿意在法律上提供帮助，但是在技术层面上，这恐怕不是那么容易。如果Salsify只是一个优良的视频编解码器或传输协议，这就会简单得多，相反，Salsify是一种将各个部分组合起来的技术形式，这意味着，在不进行重构的情况下对现有应用程序进行改造将会变得很困难，这是他们与业界对话之后得到的结论，因为他们很难拿出有效证据证明Salsify的收益是可观的，其次，目前来讲，他们也很难通过对现有应用程序进行小改动就而达到Salsify赋予的新特性。

项目简介

Salsify项目由斯坦福大学的学生们研发，并获得国家科学基金会和国防部高级研究计划署（DARPA）的资助。同时获得了谷歌、华为、VMware、Dropbox、Facebook和斯坦福平台实验室的支持。该项目相关的论文和原始数据都是对外开放的，而且源码也是开源的。