阿里云 RTC QoS 弱网对抗之变分辨率编码

简介: 本文为 QoS 弱网优化系列的第二篇

作者|安基程、田伟峰

审校| 泰一

视频编码中的变分辨率问题及解决


变分辨率在弱网场景的实际应用中非常常见,网络状况不好的时候降低分辨率可以降低码率,减少块效应,网络好的时候增加分辨率可以提升清晰度及主观体验。


目前主流的视频编码标准,比如 H.264、H.265,在编码过程中如果要进行分辨率切换,则必须要先编码一个 I 帧,而 I 帧只能使用帧内预测,编码效率低下。这在弱网变分辨率的时候就容易造成卡顿。下图中展示了每秒钟切换分辨率的码率波动效果,高低两个分辨率,每秒钟切换一次。image.png

上图中横坐标表示编码的帧数,纵坐标表示每帧的大小,图中最高的 4 个尖峰表示从低分辨率切换到高分辨率时编的 I 帧,在这 4 个尖峰中间的较低尖峰是从高分辨率切换到低分辨率编码的 I 帧。可见编码 I 帧带来的码率波动还是非常明显的,这在弱网下就很有可能造成如下图所示的卡顿。

视频中左一的男士在伸手刚接到左三女士递出的传单之时进入弱网,切换分辨率,产生了卡顿。


新一代的压缩标准,如 VP9、AV1、VVC/H.266 等都支持在做帧间预测的时候当前帧和其参考帧使用不同的分辨率,其基本思想是对参考帧做重采样 (re-sampling) 以使得其和当前帧的分辨率匹配,从而进行帧间预测,以实现分辨率切换的时候不用编 I 帧的目的。


阿里云 RTC codec 的变分辨率编码 (resolution change coding, 以下简称 RCC) 也使用和上述标准类似的基本思想,通过参考帧重采样等手段使得之前已编码的其他分辨率的参考帧也能为当前帧所用,维持帧间的参考链不断,充分利用帧间信息冗余提升压缩效率,省去编码效率低下的 I 帧。

Codec level 压缩性能测试


本文对阿里云 RTC codec 的 RCC 特性进行测试,使用 6 个视频会议序列(背景不动,运动幅度较小),和 5 个运动程度较大的序列,高低两个分辨率,一秒钟切换一次,只评价分辨率切换帧的码率和视频质量,因为对于后续的帧,使用 RCC 与否,编码方式并没有变化。


对于视频会议序列,相同视频质量下码率有 70% 节省,对于运动序列,相同视频质量下码率有 58% 的节省,因为视频内容越静止不动,帧间编码的比例越高,则 RCC 的优势越明显,所以视频会议序列 RCC 的增益比运动序列要高,是合理的。


下图展示了一个测试序列使用 RCC 后码率波动的变化,蓝线表示的是未加 RCC 的码率波动,红线表示的是加了 RCC 之后的码率波动,可以看到使用 RCC 后分辨率切换处的编码 I 帧码率尖峰明显没有了,码率更加平稳,而且视频质量 PSNR 也有所提升。image.gif

image.png

蓝线中分辨率切换处的 I 帧平均码率为 840kbps, PSNR=33.5db, 39.7db, 40.6db for Y, U, V 三个分量;而红线中分辨率切换帧的平均码率为 360kbps, PSNR=36.3db, 40.9db, 42.0db for Y, U, V 三个分量。


即开了 RCC 之后,分辨率切换时的 I 帧码率降低了近 60%,同时亮度的 PSNR 提升了近 3 个 db。

RTC level 效果


除了前述的单纯 codec level 变分辨率不编 I 帧带来的一帧的压缩性能提升之外,RCC 在和 LTR (Long Term Reference) 结合后会进一步降低弱网下频繁请求 I 帧的可能性。


LTR 抗弱网的原理在上一篇分享《阿里云 RTC QoS 屏幕共享弱网优化之若干编码器相关优化》中已有所介绍,在此结合 RCC 会进一步提升其抗弱网效果,原理如下:

1. 没有 LTR 时,在弱网场景下如果丢包或卡顿无法恢复,则会请求 I 帧;

2. 增加了 LTR 之后,则不会请求 I 帧,而是会请求 LTR 帧恢复,编码效率提升很多;

3. 如果是弱网下发生了分辨率切换,没有 RCC 的情况下,由于必须编码 IDR 帧,所以 LTR 被清空,如果此 I 帧太大,导致接收端收不到,则其会再次请求 I 帧,陷入一个恶性循环中。

4. 如果开了 RCC ,不仅分辨率切换帧本帧不会编码 I 帧,其他的参考帧管理也和之前一样,LTR 也不会被清空,分辨率切换帧本帧的大小比 I 帧减少了很多,接收端收不到的概率大大降低,即使收不到,也可以请求 LTR 恢复,而不是 I 帧恢复。


本文在 RTC level 模拟弱网场景,使其一秒钟切换一次分辨率,下面两图分别是未加 RCC 和 加了 RCC 之后的效果,可以看到未加 RCC 的画面在分辨率切换时会有明显的卡顿以及编 I 帧造成的 flicker 效应,而加了 RCC 的则会很流畅,画面也没有 flicker 效应。image.gif

图片1.gif

上图是未加 RCC,一秒钟切换一次分辨率的效果,有多次明显的小卡顿,且画面有频繁 I 帧造成的 flicker 效应。image.gif

图片2.gif

上图是加了 RCC,一秒钟切换一次分辨率的效果,整体比较流畅,感觉不到卡顿,视频质量也比较平稳,没有 flicker 效应。


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

image.png

相关文章
|
安全 数据库 C++
Python Web框架比较:Django vs Flask vs Pyramid
【4月更文挑战第9天】本文对比了Python三大Web框架Django、Flask和Pyramid。Django功能全面,适合快速开发,但学习曲线较陡;Flask轻量灵活,易于入门,但默认配置简单,需自行添加功能;Pyramid兼顾灵活性和可扩展性,适合不同规模项目,但社区及资源相对较少。选择框架应考虑项目需求和开发者偏好。
1038 0
|
9月前
|
人工智能 自然语言处理 数据挖掘
智能体来了:从 0 到 1 搭建属于你的 AI 工作流
AI 正在从“对话工具”升级为“工作伙伴”。越来越多的工作可以通过 AI 工作流自动完成,例如信息整理、内容生成、数据分析与流程执行。本文从 0 到 1 介绍什么是 AI 工作流、为什么每个人都值得拥有自己的 AI 工作流,以及如何一步步搭建一个真正能提升效率的个人 AI 工作流系统。
2639 1
|
Web App开发 存储 算法
|
Web App开发 编解码 网络协议
WebRTC SDP 详解和剖析
WebRTC 技术体系中,SDP 是看起来简单却坑非常多的点,就像直播中的时间戳几乎占据了 80% 的问题,SDP 也是问题频发的点。这篇文章详细分享了 SDP 的关键点,容易出问题的点,是非常实用的满满的干货。
WebRTC SDP 详解和剖析
|
弹性计算 异构计算
2024年阿里云GPU服务器多少钱1小时?亲测价格查询方法
2024年阿里云GPU服务器每小时收费因实例规格不同而异。可通过阿里云GPU服务器页面选择“按量付费”查看具体价格。例如,NVIDIA A100的gn7e实例为34.742元/小时,NVIDIA A10的gn7i实例为12.710156元/小时。更多详情请访问阿里云官网。
4068 2
|
开发工具 Android开发 图形学
【2015~2024】大牛直播SDK演化史
大牛直播SDK始创于2015年,旨在提供低延迟的RTMP推拉流解决方案,特别适用于毫秒级延迟的应用场景。初始版本针对Android平台实现RTMP直播推送,随后扩展至Windows、iOS和Linux平台,支持RTMP与RTSP播放器,延迟稳定在一秒以内。SDK涵盖实时推流、播放、GB28181设备接入、录像、多路流媒体转发、轻量级RTSP服务等多种功能,并支持H.265编码格式。该SDK适用于在线教育、智慧安防等多个行业场景,并已发展成为GitHub上获得超过10000星标的强大跨平台流媒体内核直播SDK。
1141 1
|
编解码 网络性能优化 芯片
阿里云 RTC QoS 弱网对抗之 LTR 及其硬件解码支持
LTR 弱网对抗由于需要解码器的反馈,因此用硬件解码器实现时需要做一些特殊处理。另外,一些硬件解码器对 LTR 的实现不是特别完善,会导致出现解码错误。本文为 QoS 弱网优化系列的第三篇,将为您详解阿里云 RTC QoS 策略中的 LTR 抗弱网原理与实现硬解 LTR 时遇到的坑及其相应解法。
阿里云 RTC QoS 弱网对抗之 LTR 及其硬件解码支持
|
JavaScript
VUE element-ui之table双表头遍历及筛选自动(回车查询)、重置、关闭dialog重置
VUE element-ui之table双表头遍历及筛选自动(回车查询)、重置、关闭dialog重置
1142 10
VUE element-ui之table双表头遍历及筛选自动(回车查询)、重置、关闭dialog重置
|
Web App开发 缓存 网络协议
揭秘阿里云 RTS SDK 是如何实现直播降低延迟和卡顿
这个夏天,没什么能够比一场酣畅淋漓的奥运比赛来的过瘾。但是,在视频平台直播观看比赛也有痛点:“卡顿” 和 “延时”。受限于不同地域、复杂的网络情况、传输速度等原因,当您还在为赛点焦灼的时候,隔壁已经传来欢呼声,观赛兴致瞬间全无。为了打造更加流畅稳定低延时的直播体验,越来越多企业关注低延时直播技术应用。
揭秘阿里云 RTS SDK 是如何实现直播降低延迟和卡顿

热门文章

最新文章