阿里云 RTC QoS 屏幕共享弱网优化之若干编码器相关优化

屏幕共享是视频会议中使用频率最高的功能之一，但在实际场景中用户所处网络环境复杂，常遇到丢包或者拥塞的状况，因此如何优化弱网环境下的用户体验也成为了音视频通讯中重要的一环。本文主要分享阿里云 RTC QoS 如何经过若干编码器相关优化提高弱网环境下的屏幕共享体验。

做者：长程/田伟峰
审校：泰一

内容说明：

本文介绍如下四个方面的优化：

• Screen Content Coding Tools
• Long Term Reference (LTR)
• Fast QP Rate Control
• Content Adaptive Frame Rate

对本文中效果测试的说明：

1. 为保证视频质量，屏幕共享的 Codec 设置了最大 QP (Quantization Parameter)，在本文后面的测试中，这个最大 QP 对全部配置都是同样的。
2. 为了更好的比较，效果测试中展现了流畅性和清晰度两个维度的效果。
3. 对于流畅性的比较，因为视频分辨率太大，因此对其画面进行了缩放，使得原始版本和改进版本能够放在同一个视野中播放，以很好的看到卡顿和延迟的改进。画面模糊是因为上述缘由降分辨率所致，在清晰度的对比中能够看到原始分辨率的画面。

Screen Content Coding Tools

Codec 中增长并改进了对于屏幕内容（其内容多为如 Word、Excel、PPT 等计算机生成的图形，文字等，具备重复纹理多，色彩分布较离散，无噪声等特色）特别适合的 Coding Tools 如 Intra Block Copy (Current Picture Reference)，Transform Skip 等，显著提高了屏幕内容的压缩效率，能够作到相对于原 Codec，对于屏幕内容视频相同质量下平都可以节省带宽 20%+，编码时间只增长 10%，对某些典型序列场景带宽能够节省 40%+，因为是非标准的 Coding Tools，实际使用中会根据 SDP 协商，当全部与会方都支持该特性时才会开启。

SCC Tools 效果

流畅性效果

测试 SCC Tools 在弱网下的改进效果。

上图中，上半部分是增长了 Screen Content Coding Tools 编码出来的码流，下半部分是原始 Codec 编出的码流，能够看出使用 Screen Content Coding Tools 以后卡顿和延迟明显下降了。

清晰度效果

上面的动图能够看到卡顿状况的改进，下图展现的是清晰度的对比，左边是原始版本，右边是增长了 SCC Tools 版本，能够看到 SCC Tools 版本和原始版本相比清晰度并无降低。

Long Term Reference (LTR)

长期参考帧技术是一种网络模块和编码器共同配合完成的参考帧选择技术。在 RTC 场景下通常的编码参考策略是向前一帧参考（在不考虑 SVC 的状况下），由于参考的距离越近压缩效果越好，出于实时的考虑编码只有 I 帧和 P 帧，没有 B 帧。而长期参考帧是一种可跨帧的参考帧选择策略，这种策略打破了传统的向前一帧的限制，能够更加灵活地选择参考帧。

长期参考帧策略的目的是在有 P 帧丢失的场景下，接收端不须要从新请求 I 帧也能继续正确的解码和播放，其相对于 I 帧能够明显提高编码效率，节省带宽。该技术能够绕过丢失的帧，利用丢失帧以前的一个已经接收的长期参考帧做为参考进行编码 / 解码显示，从而提高弱网场景下的视频流畅性。

根据长期参考帧的特色和目的，实现长期参考帧技术的应用须要有接收端侧反馈信息，编码器根据接收端反馈的帧信息选择参考帧编码，在有 P 帧丢失的场景下，接收端经过请求长期参考帧恢复将很快恢复画面。因为存在接收反馈，高 RTT 时反馈延时较大将会致使参考距离变大，因此长期参考帧比较适合低 RTT 场景。在多人会议场景中，下行人数太多也会制约长期参考帧的应用。

综合来看，长期参考帧更适合 1V1 的通讯场景，适合低 RTT 伴随丢包或者拥塞的弱网场景，这样的场景下长期参考帧比传统的向前一帧参考有更好的实时性和流畅性。

LTR 效果

测试 LTR 以及 SCC Tools 在屏幕共享弱网下的效果。

流畅性效果

上图中左上部分是没有 LTR 的效果，几乎彻底卡死，左下部分是使用了 LTR 的效果，能够看到屏幕有所滚动，比左上的更流畅。同时该场景咱们还进一步测试了增长 Screen Content Coding Tools，右边的是同时使用了 LTR 和 SCC 的效果，能够看到明显是三者中最流畅的。

清晰度效果

下图中左边是原始 Codec 效果，中间是增长了 LTR 的效果，右边是同时增长了 LTR 和 SCC 的效果，能够看到三者的清晰度并无明显差异。因为该例子咱们共享的是实时的滚屏 Log，因此三者的内容不是彻底同样的，可是整体差异不大。

Fast QP Rate Control

屏幕共享常常会有这样的场景：演讲者的桌面静止很长时间，而后翻页。对于编码器来讲，画面静止一段时间会致使 QP 逐渐下降至最小 QP，而后翻页画面突变，编码器为了控制住码率，会增长 QP。常规的编码器码率控制为了使每帧的视频质量平稳变化，会限制每帧的 QP 调整幅度，相邻两帧的 QP 变化不能太大，以获得平稳的视频观看质量体验，这样翻页时就会有一个码率的忽然增长，至码率收敛到目标码率会有一个过程，在网络好的时候没有关系，能够容忍码率的波动，可是在弱网时，该码率突增就会形成卡顿，影响观看体验。

所以，咱们增长了另外一种编码器码率控制模式，即码率快速收敛模式 Fast QP，主要原理是其能够摆脱相邻帧 QP 不能变化太大的限制，使得实际码率能够快速收敛到目标码率，而后配合网络层的带宽估计技术，在检测到弱网的时候启用这种编码器码率控制模式，使得视频码率很是平稳，观看体验更加流畅，虽然这样可能牺牲了一些相邻帧质量变化的感觉，可是此时卡顿率的体验更加明显和重要，这种平衡和取舍是值得的。

Fast QP 效果

下面展现弱网下的 Fast QP 效果。

流畅性效果

上图中一开始的那个画面（有 Twitch 单词紫色背景）是几乎静止的，只有很小范围的变化，持续了近 10 秒钟，编码器 QP 逐渐降低至很低，而后翻页到一个较复杂纹理的页面（各类分辨率卡条），此时能够看到右下的使用 Fast QP 的画面基本上能够跟得上上方本地预览画面的变化，而左下的没有开 Fast QP 的画面就卡住了，而后又翻了两页，Fast QP 版本均能跟得上变化，而没有开 Fast QP 版本直到最后一页才恢复。

清晰度效果

这里咱们只展现了翻页前的清晰度，对于翻页的清晰度，因为原始版本卡住了，因此就没有展现。左边是原始的，右边是加了 Fast QP 的清晰度，因为二者都是 QP 值降到了很低，因此清晰度都很高，没有什么差别。

Content Adaptive Frame Rate

屏幕共享的时候若是是共享桌面文档，PPT 等内容进行演讲，通常翻页速度是相对较慢的，帧率不用很高 5-10 帧每秒即足够；而有时屏幕共享也会播放电影，动画等视频，这样要求的帧率就比较高了，最好能到 20-30 帧每秒才看起来比较舒服。以下面两图，一个是编辑 PPT 的视频，明显帧率能够比较低，另外一个是广告视频，明显帧率应该高一些。

若是咱们把帧率定死，如 FPS=5，则碰到播放电影的场景就显得卡顿了；而若是咱们把帧率直接定成 FPS=30，那在通常共享文档，PPT 的场景又会形成码率的浪费。

视频编码器里的运动矢量 MV 信息能够很好的反应画面的运动情况，若是是共享的文档，PPT 等不怎么动的画面，则大多数 MV 都等于 0 的，而若是是播放电影，动画等运动较多的场景，则 MV 会有必定的数值，因此利用编码器的 MV 信息能够很好的判断当前共享视频的运动情况，选择合适的帧率。

因为编码器是原本就在那里的，因此不会增长额外的运动检测模块开销。本改进就是针对这种需求，根据屏幕共享的内容，利用编码器输出的 MV 信息，自适应的调整帧率。对于共享文档等不怎么动的画面，则放低帧率，对于共享电影动画等，则调高帧率，以达到既不浪费带宽，也能够有流畅的视频观看体验的目的。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。