惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Jina AI
Jina AI
博客园 - Franky
Apple Machine Learning Research
Apple Machine Learning Research
酷 壳 – CoolShell
酷 壳 – CoolShell
阮一峰的网络日志
阮一峰的网络日志
量子位
雷峰网
雷峰网
宝玉的分享
宝玉的分享
V
Visual Studio Blog
博客园_首页
小众软件
小众软件
The Cloudflare Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
S
SegmentFault 最新的问题
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 叶小钗
月光博客
月光博客
博客园 - 三生石上(FineUI控件)
人人都是产品经理
人人都是产品经理
WordPress大学
WordPress大学

WebRTC

基于 moq/dev 的多平台屏幕共享应用 - V2EX moq/dev 正式上线了付费 CDN - V2EX Cloudflare 最近上线了 MoQ 的中继,可以去试试看 - V2EX webrtc 的协议栈太重了,根本不想看 WebSocket 假连接与 gRPC Gateway 自动发现:复杂局域网 WebRTC 的恢复设计 有用 LiveKit 开发过视频语音会议系统的嘛? 在 window 如何处理音频 aec? 有在生产环境用过的 livekit 的吗?体验怎么样? 安卓 WebRTC 如何使用自定义的音频数据? 请推荐一个支持在线会议(仅限于音频)的 SFU 基于声网 SDK 实现 iOS 端的一对一视频通话 webrtc 有什么封装比较好的 c/c++库吗 android google 原生 webrtc setVideoProcessor 如何消费 VideoFrame I need help froma software engineer who can work with Janus gateway (WebRTC server technologies ) system . WebRTC 如何实现美颜功能 白话解读 WebRTC 音频 NetEQ 及优化实践 WebRTC 音视频同步原理与实现 light-rtc: 理念与实践 求助: serverless-webrtc-chat 在 Firefox 下失败 求助关于 WebRTC 只能在局域网建立成功问题 正在做一个开源 WebRTC 项目,有感兴趣的小伙伴吗。 sharedrop P2P 文件分享 webrtc 不是才有的技术,应用领悟主要是网页端,现在安卓版本更新很快,为什么内置浏览器不支持这种几年前就有的新技术,这个不合理 Webtorrent 在内网环境进行播种的想法 能否用 WebRTC 做一个局域网的视频播放服务? 求助各位大神,国内目前主流浏览器支持 MediaRecorder 吗? 公司要测试 webrtc 是不是买个国内阿里云什么的? kurento room 服务端 Python 适配时 iceCandidate 内容怎么设置 kurento 的 Python 改造问题 [ 北京] WebRTC Meetup, 1 月 8 日 node-party @ 微软大厦,报名从速 !
阿里云 RTC QoS 弱网对抗之变分辨率编码
VideoCloudTech · 2021-04-02 · via WebRTC

作者|安基程、田伟峰

审校| 泰一

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

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

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

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

https://v.youku.com/v_show/id_XNTEzMTY3MzU5Ng==.html

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

新一代的压缩标准,如 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 也有所提升。

蓝线中分辨率切换处的 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 效应。

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

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