Salsify: 低延迟的网络视频框架设计--视频编解码器和传输协议的紧密集成

本文出自论文Salsify: Low-Latency Network Video through Tighter Integration between a Video Codec and a Transport Protocol，对其论文内容进行了基本总结，这里提出了用于实时视频系统的Salsify，结合了视频编解码器和传输协议中的率控制算法，来避免引发丢包和自身流量的排队延迟。

---

Salsify是一个专门用于实时网络视频的架构，它紧密集成了一个视频编解码器和一个网络传输协议，允许它快速响应变化的网络环境，避免造成数据包丢失和排队延迟。Salsify基于网络容量的一个当前评估，来优化每帧的压缩长度和传输时间。Salsify的每帧优化策略依赖于一个纯功能视频编解码器，用它来探索每帧不同质量级别的可替代编码。Salsify实现了在可变网络路径上较低的视频延迟，以及更高的视频质量，其对比系统为：FaceTime, Hangouts, Skype, WebRTC。

---

一、简介

1. 当前实时视频系统通常由两个组件所组成：传输协议和视频编解码器。传输协议负责传输压缩视频给接收者，处理确认和拥塞信号，然后预估网络路径上的平均数据速率，并把预估的数据速率反馈给编解码器模块。编解码器选择编码参数（帧率和质量设置），然后生成一个压缩视频流，其平均码率接近于所预测的网络容量，从而可以保证视频的完整传输，而不会产生卡顿或者掉帧现象。
2. Salsify结合了传输协议的packet-by-packet拥塞控制和视频编解码器的frame-by-frame率控制，通过匹配网络变化容量和视频传输速率，来避免引发网络缓冲区溢出或排队延迟。Salsify的视频编解码器在不同的质量水平上探索每个视频帧的替代编码，来使压缩长度符合网络瞬时容量。当网络可以容纳视频帧时，则发送对应的视频帧。

二、相关工作

1. Adaptive videoconferencing(自适应视频会议)：Salsify将每个组件的率控制算法合并为一个，利用视频编解码器的功能特性，来使每个压缩帧的长度保持在传输方对网络容量的瞬时预估内。
2. Joint source-channel video coding(融合源-信道视频编码)：之前的工作集中于将源编码（视频压缩）与信道编码（前向纠错）结合起来，以便应用程序能够应对独立随机过程引起的丢包和延迟问题。Salsify在视频编解码器中融合了率控制算法和传输协议，来避免引发丢包和排队延迟。
3. Scalable or layered video coding(可扩展或分层视频编码)：在可扩展编码中，编码器产生多流压缩视频，它由一个基础层和多个增强层所组成，其中增强层用来提高较低层的质量，包括帧率、分辨率或者视觉质量。在实时视频应用中，当网络拥塞时，应用程序可以立刻丢弃增强层，而无需等待视频编解码器进行自适应过程。
   
4. Loss recovery(丢包恢复)：传统的RTP和WebRTC应用在发生丢包时，要不重传所丢失的包，要不重新编码一个视频帧的丢失slice。Salsify的功能性视频编解码器保留了旧状态的记忆，直到发送者丢弃它们。如果一个网络出现丢包现象，编码器可以开始以一种只依赖接收方已经承认的较旧状态的方式编码新的帧。

三、设计与实现

1. 在WebRTC的开源实现框架中，视频编解码器以特定帧率从原始视频中读取帧并压缩它们，它以特定的平均比特率为目标。传输协议在大约1s的时间尺度上，更新编码器的帧率和目标比特率。WebRTC的拥塞响应通常是反应性的，如果视频编解码器产生的压缩帧超过网络容量，继续进行传输，即使会导致丢包或缓冲区溢出，随后再告诉编解码器暂停编码新的帧，直到不再拥塞。而Salsify架构允许在每帧被压缩前，传输协议与视频编解码器交流网络状态，从而使其传输可以匹配网络容量的变化状态，如果当前网络可以容纳压缩帧时则进行编码操作。

2. Salsify的传输协议预估网络可以安全接收的字节数量，从而不至于丢包或者排队延迟，尽管在编码帧开始前该字节数量已知，但是预测编码器参数来使一个视频编码器匹配一个预先指定好的帧长度却具有一定的挑战性。Salsify尝试两组不同的编码参数以确定可用容量，该系统会首先检查压缩帧的编码大小，并选择其中一个合适的去发送，来匹配网络容量。编码该帧的状态被恢复，用作下一个编码帧的基础。

3. 使用编解码器接口，我们可以利用不同质量参数配置来编码每帧和从所需状态开始解码。这允许Salsify以一定大小和质量来编码帧，从而满足网络容量限制，同时可以有效地从丢包中恢复。编解码器接口定义如下：
   d e c o d e ( s t a t e , f r a m e ) → ( s t a t e ′ , i m a g e ) e n c o d e ( s t a t e , i m a g e , q u a l i t y ) → f r a m e decode(state,frame)\rightarrow (state',image)\\ encode(state,image,quality)\rightarrow frame decode(state,frame)→(state′,image)encode(state,image,quality)→frame

4. 编码来匹配网络容量：Salsify利用视频编码器的功能特征来优化每个私有帧的压缩长度，这个基于对网络容量的一个当前估计值。通过串行或并行运行两个编码器，来为每个帧探索两个压缩级别，初始化时使用相同的内部状态，但其质量设置参数有所不同。Salsify选择最匹配网络容量的结果帧，在知道压缩帧的确定大小之后尽量推迟发送哪个版本的决定。当两个不同版本的编码帧都超过网络容量时，Salsify通过跳帧的方式来适应当前网络状态。

5. 丢包恢复：当发送方检测到丢包时，它将通过创建依赖于接收方已经确认状态的帧，来重新同步接收方的状态。该方法要求sender和receiver在内存中保留目标状态序列，仅当不需要的时候再删除。

6. Salsify传输协议：每帧的头部包含着源状态和目标状态的hash值，receiver在内存中存储目标状态，以防sender需要使用此状态做丢包恢复。对网络状态的预估值在确认包中被传递给sender。由于在当前帧的最后一个fragment和下一个帧的第一个fragment之间存在间隔，会被误认为当前网络拥塞，因此sender会在每个fragment中包含一个grace period，告诉receiver两个fragment之间的间隔时间。在sender端，基于receiver发送的最近平均inter-arrival时间 τ i \tau_i τi​，来预估一个帧的期望大小值。首先，通过对上一个发送包和上一个接收包的索引值计算，sender预估得到in-flight的包数量 N i N_i Ni​。如从果sender如果想要保持端到端延迟少于d，则in-flight包数量不应当超过 d / τ i d/\tau_i d/τi​，因此目标大小为 ( d / τ i − N i ) (d/\tau_i-N_i) (d/τi​−Ni​)MTU-size fragments。如果连续跳帧4次，则sender直接发送较低质量版本的帧。
   τ i ← α ( T i − T i − 1 − g r a c e p e r i o d i ) + ( 1 − α ) τ i − 1 . \tau_i \leftarrow \alpha(T_i-T_{i-1}-grace_period_i)+(1-\alpha)\tau_{i-1}. τi​←α(Ti​−Ti−1​−gracep​eriodi​)+(1−α)τi−1​.
   

7. Salsify传输协议的算法过程描述：

   （1）根据上面公式计算mean_interarrival_time;

   （2）根据发送包和接收包索引来计算num_packets_outstanding;

   （3）根据预先定义的端到端最低时延，计算得到当前网络状态最大可以接收的帧大小。
   

8. Salsify编解码器算法过程描述：

   （1）获取source_state，如果发生丢包则进入丢包恢复模式，将已有的接收方编解码状态当成source_state，否则以上一个发送帧的目标状态作为source_state；

   （2）设置两组不同的编码参数表示低质量和高质量的编码方案，进行帧编码；

   （3）根据网络容量，即当前网络最大可以接收的帧大小，来选择合适的编码帧；

   （4）如果没有合适的编码帧，则进行跳帧，当连续跳帧4次时，则直接选择低质量的编码帧来发送。

四、Salsify评估

1. 评估准则：SSIM用来评估视频质量，将原始视频和接收帧来进行比较，这里使用了Xiph Daala工具包。对于测量交互视频延迟，则计算提供一个帧到接收该帧的时间。

2. 视频分析：为了计算与视频相关的度量准则，测试台记录发送端呈现每一帧的时间，从接收端捕获显示输出，并为到达的每一帧时间戳标记到同一个时钟。本文在视频的每一帧上添加两个二维码，分别代表着发送帧和接收帧的标记信号，每个二维码编码一个64位的随机数，并在整个视频过程中是唯一的，从而来表示相同的帧。

3. 评估设计架构：它模拟了一个网络摄像头，向发送者提供原始视频画面，sender通过以太网传输视频帧给receiver。
   

4. 对比方案：
   

5. 将传输协议移除后，Salsify低估了网络容量，从而发送低质量低码率的视频帧。将编解码器移除后，使用传统的编解码器进行替代，其实验性能也有所下降，其原因有以下两种：（1）传输协议无法在传输时间内选择视频帧，如果网络容量发生变化Salsify可能发生延迟或者不能提高视频质量；（2）为任何编解码器选择合适的质量参数来满足目标大小是一个挑战。将传输协议和编解码器移除，而对网络平均数据速率进行评估，再每一秒更新视频编解码器的质量参数，其实验性能等同于Skype和WebRTC。
   

6. 在不同网络环境下的性能比较：
   
   

7. 当网络状态快速变化时，Salsify可以快速响应改变，Salsify的发送数据速率随着网路容量平稳下降，然后平稳恢复，同时Salsify视频播放也会快速恢复。
   

8. 在一个固定数据速率同时间隔性一秒内丢包的网络环境下，我们比较了Salsify和WebRTC的反应性能。Salsify总是根据receiver端可获得的参考状态来编码最近的视频帧，而WebRTC的传输协议则在视频编码器开始编码新帧前来重传丢失的包，因此会造成视频延迟和帧率的巨大变化。
   

五、结论

1. Salsify的loss-recovery策略要求sender和receiver在内存中同时保持一组解码器状态，便于在丢包发生时从已知状态中恢复。
2. Salsify的功能性编解码器的好处在于它可以通过试错来生成压缩帧，从而使其长度可以匹配传输协议对网络瞬时容量的预估。
3. Salsify结合了视频编解码器和传输协议中的率控制算法，来避免引发丢包和自身流量的排队延迟。
4. 在一个end-to-end的评估中，Salsify达到了较低的end-to-end视频延迟和较高的质量，对比的已有系统包括：Skype, FaceTime, Hangouts, WebRTC视频会议(是否使用可扩展视频编码VP9-SVC)。