揭秘:腾讯会议背后的视频编码“神器”

2020 年 12 月 16 日

揭秘:腾讯会议背后的视频编码“神器”

作为一款实时音视频通信产品,腾讯会议里面有海量的音视频数据需要进行实时传输,比如我们的摄像头画面,屏幕分享的数据等。这些数据量非常庞大,通常需要经过编码压缩再进行传输,那么腾讯会议里有哪些视频编码方面的”神器”呢?


一、时域 SVC


在视频编码中,有三种帧类型:


  • I帧:只能进行帧内预测,可以独立解码;

  • P帧:单假设参考帧,也就是通常说的前向预测帧,只能使用它之前的帧进行预测;

  • B帧:双假设参考帧, 一般为双向预测帧。


由于 B 帧会带来不可避免的延迟,因此在实时通信中通常只使用 I 帧和 P 帧这两种帧类型。


I 帧只使用了本帧的信息进行预测,也就是说 I 帧的解码不依赖于其他帧,因此可以独立解码,但 I 帧的编码效率偏低,数据量较大。


P 帧使用了帧间预测方法,可以参考之前的一些解码帧信息,能达到较高的压缩效率(帧大小比 I 帧小很多),但是解码时必须依赖于其他帧。


在实际的应用场景中,为了提升压缩效率,往往会使用 IPPP 的帧结构,即 I 帧之后编码 N 个 P 帧。但当网络情况不好时(如抖动,丢包,限速等),这种帧结构就会造成长时间的卡顿。


如下图所示,第 0 帧为 I 帧,后续 7 个帧均为 P 帧,且每个 P 帧只有一个参考帧(为其前一帧)。当网络发生丢包时,第 3 帧丢失,由于第 4 帧参考第 3 帧进行压缩,因此不能正确解码,5~7 帧则类似。


这种情况下,即使丢包只造成个别帧的丢失,但由于接收端很多帧不能正确解码,会造成长时间的卡顿,只能通过申请 I 帧的机制进行恢复。



为了解决这一问题,我们加入了时域 SVC 技术,对参考帧结构进行了调整。



我们可以将视频帧分为若干层,上图以 3 层为例:


  • Layer0的帧只能参考同样为Layer0的帧,不能参考Layer1和Layer2的帧;

  • Layer1的帧可以参考Layer0和Layer1的帧,不能参考Layer2的帧;

  • Layer2的帧可以参考Layer0~2的帧。


越低层级的帧被参考的可能性越大,因此重要性也越大。在网络发生丢包时,只要所丢的帧不是 Layer0 层,就不需要重新申请 I 帧,解码端就可以持续成功解码。如上图中第 1 帧丢失仅会影响 2,3 帧,其他帧不会受到影响。


此外还可以结合网络层的策略,对低层级的帧多加一些保护(如 FEC),降低其丢失的概率,能有效地解决卡死的问题。


在参会的下行人数很多时,可能会有小部分下行网络较差,如果采用传统的 IPPP 结构,则当某个下行损伤时就需要不断的申请 I 帧来恢复,这样就会影响到其他接收端的视频体验;如果采用时域 SVC 的结构,在能够保证少数的下行网络存在问题时,其他的下行端不会受到影响。


说了这么多,我们来看一下实际的效果吧!第一个视频示例是 IPPP 结构在网络损伤时的表现,卡顿感很明显;接下来是采用时域 SVC 的版本,帧率会有所影响但整体还算流畅。


00:00 / 00:00
    1.0x
    • 2.0x
    • 1.5x
    • 1.25x
    • 1.0x
    • 0.5x
    网页全屏
    全屏
    00:00


    00:00 / 00:00
      1.0x
      • 2.0x
      • 1.5x
      • 1.25x
      • 1.0x
      • 0.5x
      网页全屏
      全屏
      00:00


      二、ROI 检测以及基于 ROI 的编码


      摄像头内容是腾讯会议中的一个主要视频场景。在此场景中,人眼往往比较关注人脸区域,对背景区域的关注度较低。因此,我们加入了人脸检测算法和基于感兴趣区域(Region of Interest, 简称 ROI)的编码算法。


      这类算法的主要思路是:实时地检测出当前视频中的 ROI 区域,将其传入到编码器内部,编码器进行单帧的码率重分配。对 ROI 区域,增大其码率,能使该区域编码的更好,提升主观质量;对于非 ROI 区域,降低其码率,则总的码率不会超出目标码率。


      在 ROI 检测方面,因为腾讯会议是一个实时性要求很高的场景,对算法复杂度很敏感,我们使用一些传统的算法,结合编码器的一些预分析结果,确定最终的 ROI-map,对于 1080p 的视频,单帧检测耗时在 0.3ms 以内,完全满足了实时性的要求。


      基于 ROI 的检测和码率调整算法的优点在于:在低码率的情况下,能极大地提升主观质量;在高码率的场景下,可以保持主观质量基本不变,码率节省 20%~30%,以下是一些对比效果:


      低码率效果对比 (左)关闭ROI  (右)开启ROI


      高码率效果对比 (左) 300kbps, 关闭ROI  (右) 210kbps, 开启ROI


      三、屏幕内容编码技术


      屏幕分享/白板等屏幕类内容是腾讯会议中另一类视频场景。屏幕生成的视频与摄像头采集的视频存在很大的不同:屏幕视频通常没有噪声,色调离散,线条细腻,边缘锐利;相反的,摄像机拍摄的视频通常存在噪声,色调连续且丰富,纹理比较复杂。


      传统的 H.264 和 H.265 编码器采用的是基于块的混合编码框架,包含预测,变换,量化以及熵编码。其中变换模块主要的目的是将残差信号从空域变换到频域,使信号能量更集中,也方便基于不同的频率分量做不同的处理,减小编码所需的比特数。


      但是,对屏幕分享的内容,采用基于变换的编码方法,会损失其高频细节,导致用户观看的视频变得不清晰


      基于上述原因,我们在 H.265 编码器中加入了一些有效的屏幕内容编码技术(Screen Content Coding,简称 SCC),包括帧内块拷贝和调色板编码。


      我们在前面的介绍中也提到过,一般情况下 I 帧编码效率要比 P 帧差,主要原因是 P 帧可以利用时域上的信息进行预测,预测精确度往往很高,这样编码的信息量就变少了。


      如下图所示,第 N 帧与第 N-1 帧之间只有很少量的运动,所以用第 N-1 帧的信息来预测第 N 帧相对来说会很准确。



      所谓的帧内块拷贝,是指借鉴了帧间预测的方法,在 I 帧中引入基于运动矢量(Motion Vector, 简称 MV)的预测,提升其预测精确度,极大地提升了 I 帧的压缩效率。


      该方法之所以在屏幕类场景效果显著,是由于屏幕序列相比于摄像头采集序列有很多重复性的图案,用这个方法效果更好。



      在屏幕内容中,像素点的选择通常集中在某一些色彩上,所以我们引入了调色板模式。该模式彻底抛弃了传统的变换编码的方法,直接依据像素点的“颜色值”生成调色板。


      对每个像素点,传输其在调色板中的“索引”(“index”)即可。该算法可以达到很高的编码效率提升,同时这种方法由于不使用变换,且大多数的点可以在颜色表中找到对应的项,主观质量也有明显的提升。


      四、YUV444 编码


      在视频编码中,基本的数据格式为 YUV,根据采样格式的不同可以分为 YUV444, YUV422 以及 YUV420,这三种格式的区别见下图(O 表示 Y 分量,X 表示 U/V 分量):


      YUV采样格式 (左)YUV444  (中)YUV422  (右)YUV420


      YUV444 采样格式中 Y、U、V 三个分量的比例相同,每个像素的三个分量信息完整,都是一个字节。YUV422 采样格式中 Y 分量和 UV 分量则按照 2 : 1 的比例采样。如图所示,水平方向有 4 个像素点,那么就采样 4 个 Y 分量,2 个 UV 分量。


      YUV420 采样格式中,每一行扫描时只扫描一种色度分量(U 或者 V)且该色度分量与 Y 分量按照 2 : 1 的方式采样。如图所示,为了直观的理解,我们认为 4 个 Y 分量对应 1 个 UV 分量,因此将 X 放在了四个 O 中间。


      一般来说,大多数的视频类应用都采样 YUV420 的格式进行编码,一方面这种格式数据量较少,另一方面色度分量的重要程度明显低于亮度分量,对色度降采样后人眼主观感受降低不明显。


      然而,在屏幕分享场景中,相比于摄像头采集序列,U/V 分量信息更丰富,下采样会严重的丢失这部分信息,且在后续的后处理等环节无法补回,所以我们加入了 YUV444 编码的支持。


      大家可以看下下面这两张图,我们人为生成了一张 U/V 分量信息很丰富的图片,在发送端可以看到是有色彩的,但是经过 YUV420 采集编码传输后,到接收端看到的却是一幅灰度图像,失真非常严重。




      在屏幕分享场景下,有些时候可能会对色彩的保真度/还原度要求较高,如一些设计图像等,那么加入 YUV444 的支持就是为了在这些场景下达到不错的用户体验。下面是我们实际测试到的 YUV420/YUV444 编码下的对比图:


      原图


      YUV420编码图像


      YUV444编码图像


      五、业界领先的编码器


      我们对 H.264 和 H.265 编码器进行了深度优化,一方面加入了很多快速算法,提升其编码速度;另一方面加入了一些新的编码工具集,提升其压缩效率。


      与业界最著名的 x264 开源编码器相比,我们的 H.264 编码器针对屏幕分享内容做了大量的优化,达到了 40%以上压缩效率的提升,编码速度仅损失 11%左右。


      我们的 H.265 编码器无论在屏幕分享场景还是摄像头场景,都远远优于开源的 x265 编码器。与 x265 相比,在屏幕分享场景下,压缩效率提升多达 83.7%,速度提升 210%;在摄像头场景下,压缩效率提升 24.7%的同时速度可以提升 140%左右。

      结语


      本文较为详细的介绍了一些腾讯会议中的视频编码“神器”,为了不断地提升产品体验,我们会根据不同的场景持续优化我们的编码器,增加适合的编码技术,欢迎大家咨询体验!



      头图:Unsplash

      作者:张清 - 腾讯多媒体实验室高级研究员

      原文揭秘:腾讯会议背后的视频编码“神器”

      来源:腾讯多媒体实验室 - 微信公众号 [ID:TencentAVLab]

      转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。


      2020 年 12 月 16 日 22:411059
      用户头像

      发布了 31 篇内容, 共 16648 次阅读, 收获喜欢 10 次。

      关注

      评论

      发布
      暂无评论
      发现更多内容

      快速开发平台,高集成易扩展,进入软件疾速开发新世代

      Marilyn

      敏捷开发 快速开发 开发工具

      TensorFlow 篇 | TensorFlow 2.x 基于 Keras 的模型保存及重建

      Alex

      tensorflow keras model save model restore tensorflow hub

      Go语言内存管理三部曲(一)内存分配原理

      网管

      go 内存管理 内存布局

      JVM-技术专题-对象的实例化过程

      李浩宇/Alex

      Java JVM

      MySQL-技术专题-性能优化—索引篇

      李浩宇/Alex

      架构师训练营 1 期第 4 周:系统架构 - 作业

      piercebn

      极客大学架构师训练营

      百度人工智能OCR调用调试过程

      tuuezzy

      Lindorm云原生数据库 - 让数字时代IT运维系统“灵动”起来

      许力

      DevOps APM Data Lake AIOPS

      阿里面试官纯手打:金九银十跳槽必会Java核心知识点笔记整理

      Java架构追梦

      Java 数据库 架构 面试 微服务

      数字货币交易所开发,币币交易源码

      135深圳3055源中瑞8032

      合约跟单交易系统开发,一键智能跟单软件

      135深圳3055源中瑞8032

      医疗AI系统构建(1)one-hot编码

      刘旭东

      人工智能 学习 医疗AI one-hot

      一线城市年轻人生活工作实录(程序员篇)

      Marilyn

      敏捷开发 开发者工具 快速开发

      有一说一,大型信息化企业的软件系统,还是用自研的好

      Marilyn

      敏捷开发 快速开发 开发工具 软件设计

      为什么巨头都在布局SaaS生态?

      ToB行业头条

      SASS

      用友政务表格技术应用开发实践:预算一体化产品核心功能搭建

      Geek_Willie

      SpreadJS 用友

      Redis Sharding集群跟一致性哈希有什么瓜葛?

      Man

      一致性哈希 Jedis redis cluster

      一线城市年轻人生活工作录(业务员篇)

      Marilyn

      敏捷开发 快速开发

      大企内部软件系统反复故障难以解决,业内人士:唯有彻底更换

      Marilyn

      敏捷开发 快速开发 开发工具

      阿里内部《Java架构进阶宝典》,总结了基础、进阶、架构三个阶段的知识点

      Java架构之路

      Java 程序员 面试 算法 编程语言

      区块链钱包软件开发费用,区块链多币种钱包

      135深圳3055源中瑞8032

      企业开发遇到瓶颈,何不换个新思路?快速开发了解一下

      Marilyn

      敏捷开发 快速开发

      微前端之如何拆解React巨石应用 qiankun

      SugarTurboS

      项目管理 架构 React 微前端 前端性能优化

      WSDM Cup 2020大赛金牌参赛方案全解析

      华为云开发者社区

      大数据 搜索 信息

      区块链USDT支付系统开发需要多少费用?USDT跨境支付

      135深圳3055源中瑞8032

      有了TA,领域外企业里的小IT团队,也能轻松搞定大型项目

      Marilyn

      敏捷开发 快速开发

      GitHub 上开源了一个很邪恶的项目!女生勿近,18香警告...

      程序员生活志

      JVM-技术专题-深入理解内存结构

      李浩宇/Alex

      Java JVM

      五年Java开发经验,4面阿里成功拿下offer,分享一下个人面经!

      Java架构之路

      Java 程序员 面试 算法 编程语言

      医院HIS故障,险引发人命关天大危机,竟被程序员轻松解决!

      Marilyn

      阿里P8大牛呕心沥血总结整理的《Java面经手册》,通过实践的方式向你深度讲解Java核心知识点

      Java成神之路

      Java 阿里巴巴 程序员 面试 编程语言

      揭秘:腾讯会议背后的视频编码“神器”-InfoQ