重新设计实时视频传输

斯坦福大学(Stanford University)一个名为Salsify的学术研究项目已经确定了一种更好的方式，可以为电话会议等实时应用提供视频.

他们并没有创造一种新的视频格式，而是为实时视频系统创造了一种新的架构. 而不是使用两个独立的控制回路的现状, 一个用于传输，一个用于视频编解码器, Salsify方法将这些连接到一个统一的控制回路中，一起管理传输和视频编解码器.

视频编解码器目前就像一个黑盒子——它有编码/解码功能，可以将视频转换成合适的大小以供传输, 然后是传送视频的传输协议. Salsify项目使整个系统对可用带宽的变化更具响应性. 其结果是，至少在理论上，一个更好的整体体验. 那么今天的情况如何呢?

当前状态

视频编解码器和传输协议各自在某种程度上独立运行, 导致视频流对于网络来说可能太大或太小. 斯坦福大学博士候选人和Salsify项目成员Sadjad Fouladi想要平衡传输的视频是否符合网络条件的可能性, 因此，出现故障和掉线的情况更少, 以及更少的缓冲.

他们创建了一个实时视频系统，能够快速响应不断变化的网络条件，避免停机和故障. Salsify查看当前对网络容量的估计，然后提供在这些情况下可以传输的视频帧.

他们的研究项目声称可以实现比市场领先者facetime更低的视频延迟和更好的视觉质量, 谷歌视频群聊, Skype, 以及WebRTC在谷歌Chrome浏览器中的参考实现，包括带和不带可扩展视频. 用于视频会议中的实时通信, 远程医疗, 或者其他不能接受视频传输延迟的用途, 低延迟甚至比直播更重要.

“我们知道，很多人在视频会议中受到连接不良和视频质量低的困扰,弗拉迪说。. “我们认为问题不在于编解码器，也不在于传输. 而是我们将这些组件整合在一起的方式."

“不幸的是，这些系统的整体性能并没有提高多少, 所以我们认为也许是时候为整个系统设计一个新的架构，而不是改进单个组件,他说.

低，低延迟

在Skype等产品或WebRTC等协议中, 传输协议对流没有太多的控制. 即使现在不是发送东西的好时机，因为连接不良或已经拥挤的网络, 传输协议仍然必须发送已经编码的帧, 说Fouladi.

今天，传输协议对传输到视频编解码器的网络速度有一些估计. 单个帧的输出大小通常低于或超过估计的网络速度. 如果这一帧太大或太小，它会尝试通过调整下一帧来进行补偿.

在大约10到20帧的过程中，它达到了平均网络速度，Fouladi说. 因此，虽然自我纠正机制在理论上听起来不错, 实际上，大帧仍然会导致拥塞和丢包, 这将导致流的延迟. 另外, 仅实现平均比特率会使系统对网络中的变化反应缓慢.

幕后故事

Salsify只关心下一帧的大小, 而以前的编解码器试图基于平均比特率传输内容. 目标是确保没有单个帧会在网络中造成丢失和拥塞. 而不是事先不准确地猜测编码参数, Salsify的方法为每个视频帧创建两种略有不同的质量，然后选择适合网络条件的质量，并在持续的基础上进行调整. 就这样, 传输对视频有逐帧控制，可以更快地响应不断变化的网络条件,弗拉迪说。.

这种方法(为传输提供选项菜单)是由Salsify的功能性视频编解码器实现的，该视频编解码器为视频编解码器提供了保存/恢复状态接口, 允许它探索不同的执行路径，而无需向它们提交. 在传统编解码器中, 如果一个帧被编码, 它成为视频流的一部分，必须被发送, 而在Salsify的编解码器中, 它可以被丢弃，可以恢复旧状态.

“所以在这种情况下, 例如, 如果网络坏了或者发生了什么不好的事, 传输可以完全停止发送帧，以避免造成更多的拥塞, 即使编解码器已经生成了一个帧,弗拉迪说。. 该项目使用了团队自己实现的VP8编解码器，并实现了4.6x低p95延迟和2.与FaceTime, Hangouts, Skype和WebRTC相比，平均视觉质量提高1 dB SSIM.

“现在我们实际上可以进入黑匣子的内部, 我们可以设计更复杂的系统，可以做更多他们目前能做的事情,弗拉迪说。. “我认为这个项目的目标之一是展示拥有这个接口的好处，并以某种方式说服编解码器设计师和实现者在未来几代编解码器中实际包含该接口."

Salsify开源编解码器只有视频(没有音频). 该项目是基于软件的，每一帧编码两个版本的要求产生了显著的计算开销，使其远离黄金时间. 要在硬件上实现这一点，他们将经历与AV1相同的漫长道路, 因此，需要一些创造性的思考，来研究如何将其应用到现实世界中. 虽然他们有很多挑战, Salsify团队开发了一种有趣的方法来解决一个长期存在的问题.

更多信息可在 http://snr.stanford.edu/salsify.