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

69次阅读

共计 3235 个字符,预计需要花费 9 分钟才能阅读完成。

屏幕共享是视频会议中应用频率最高的性能之一,但在理论场景中用户所处网络环境简单,常遇到丢包或者拥塞的状况,所以如何优化弱网环境下的用户体验也成为了音视频通信中重要的一环。本文次要分享阿里云 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 信息,自适应的调整帧率。对于共享文档等不怎么动的画面,则放低帧率,对于共享电影动画等,则调高帧率,以达到既不节约带宽,也能够有晦涩的视频观看体验的目标。

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

正文完
 0