阿里云 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 信息，自适应的调整帧率。对于共享文档等不怎么动的画面，则放低帧率，对于共享电影动画等，则调高帧率，以达到既不浪费带宽，也可以有流畅的视频观看体验的目的。

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