在实时通信领域,只有当Codec的优化适应了当前的网络状况,设备平台及应用场景,用户才能得到最佳的体验。在LiveVideoStackCon2018大会中声网Agora视频工程师吴晓然详细介绍了如何设计与实现基于QoE的实时视频编码优化。本文由LiveVideoStack整理而成。

文 / 吴晓然

整理 / LiveVideoStack

大家好,我是吴晓然。本次将为大家介绍基于QoE的实时视频编码优化探索。实时音视频的传输框架大同小异,虽然不同厂商在一些技术细节的打磨上略有差异,但都有一个共同的目标那就是QoE——用户体验质量。那么其根本原因何在?

首先,互联网时代本身主要面向用户,用户体验是是衡量产品价值的重要维度,从用户的角度出发进行优化无可厚非;其次,基于用户体验的优化是当下最好的选择,目前我们的学术积累相对于欧美发达国家仍有一定差距,单纯地依靠学术创新推动技术改革的道路不但效率较低,也会影响到我们追赶时代潮流的步伐,故而我们可以从优化用户体验的角度出发,实践一些有用的创新举措从而推进技术的改革;最后,中国拥有全世界最大的互联网消费群体,我们的互联网日活跃量都是以亿为单位计量,庞大的用户基数下蕴含着宝贵的数据财富,这些数据对任何一家互联网企业而言都是一种无形的巨额资产。数据是21世纪的石油,谁能够充分发掘数据背后的价值谁就能成为市场的主导者,为用户提供更优质的服务,打造更优秀的产品。

本次分享内容将主要围绕以下几个方面:

1. 实时视频通讯的QoE

理想条件下,采集端获取到的原视频数据会经过前处理、编码后通过网络传输至解码端,解码端接收数据处理后再进行后处理与渲染,最后得到输出的视频产品。如果输出视频产品清晰度不佳那么我们可通过提高分辨率、减小QP、增加算法复杂度等方法提高清晰度;而如果流畅度不佳那么则可通过提高fps的方法优化流畅度。

但在现实条件下,不稳定的网络使得在网络传输流程中易出现带宽变化、延时抖动、网络丢包等不良状况:即使我们有带宽预测的算法,但带宽变化的不可预知性仍然是困扰我们的一大难题;延时抖动更是任何一个网络中或多或少都会发生的状况;而随机丢包对实时传输造成的影响最大,当网络状况很差时高丢包率会导致视频播放相当卡顿并且无计可施。面对这些问题时,单纯地提高分辨率、减小QP、增加算法复杂度或提高fps只会加剧带宽的占用并增加处理时间与功耗,其结果就会导致网络拥塞、使得实时性无法达到要求,尤其移动端的用户体验会被大打折扣,继而出现手机发热、待机时间下降等诸多不良状况。

根据理论与实践我们总结得出基于QoE的实时视频编码优化目标为:终端显示高质量、接受端低延时、发送端低功耗。

2. Agora的探索与实践

明确了实时视频编码优化目标之后,与大家分享一下我们在此方面进行的探索与实践。我们的优化策略可以大致分为三个部分:前处理、编解码、后处理。

2.1 前处理

1)基于机器学习的带宽估计

在之前的内容当中有提到带宽估计的难以预测性。这表示即使我们获取了十分全面的参数,也难以准确借助一种经典模型或算法准确预测带宽量。但是在神经网络与机器学习的帮助下我们可以较为准确地估计带宽的动态变化。通过上亿帧针对带宽、延时、jitter、丢包率、接收端的buffer size、分辨率、FPS等一系列参数设计的强化学习训练神经网络从而使其具备预测下一时段带宽量的能力,这是一种区别于传统经典模式的全新解决思路。当然此方法并不适用于所有网络模型,如在一些网络状况较好抖动延时并不严重的情况下使用经典模型优化也可获得良好效果;而当处于随变性很强的网络环境中时,机器学习也许会让问题迎刃而解。

2)帧率及分辨率自适应调整

实时通讯包括很多不同场景,而视频帧率与分辨率的参数调整和视频内容或场景紧密相关。例如我们可以对一些场景变化较轻微的画面采取适当降低帧率的方式减轻带宽与数据压力,而对一些场景变化激烈的画面如动作片打斗等则不能采取降低帧率的方法,否则观众可轻易察觉到帧率降低造成的画面模糊与卡顿。

我们应当根据不同的视频内容场景匹配调整不同的参数,如对清晰度要求很高而流畅度要求较高的直播场景而言,可以通过调整其帧率实现对实时编码前处理过程的优化;而对流畅度要求很高的通讯场景而言,则可以在保证清晰度的同时通过调整分辨率来优化实时编码的前处理过程。因为在一般情况下,采用视频通讯交流的双方彼此都比较熟悉,在可接受范围之内降低分辨率不会为二者交流带来明显障碍;而一旦出现卡顿或延时则会直接导致双方交流沟通的不畅甚至失败,使用户体验大打折扣。

教育场景对清晰度与流畅度的要求都非常高,其原因在于教育场景背后行业的巨大投资与学术严谨。家长对孩子的大笔投入,使得这些孩子值得通过更高质量的音视频收获严谨的知识。

对游戏场景而言,虽然良好的清晰度与流畅度都至关重要,但流畅度是需要首先保证的参数。特别像是对一些实时战略游戏而言,有时游戏就在几秒甚至几百毫秒间分出胜负。早年参加WCG大赛的选手为了避免液晶显示器刷新率低导致的拖影对游戏比赛造成不良影响,会优先使用CRT显示器上场比赛。

总而言之,根据视频的不同内容场景自适应调整帧率与分辨率,是一种有用的实时编码前处理优化策略。

2.2 编解码

1)区域检测及ROI编码

区域检测及ROI编码属于前处理且与Codec相结合。区域检测可用于前景与背景检测、画质增强、美颜特效等;而落实到Codec层面则用于ROI编码。ROI编码可明显增强特定场景中局部画面的画质,如对流畅性与清晰度要求都很高的游戏应用场景而言,如果码率无法达到流畅性与清晰度的要求,那么我们可在编码时通过ROI编码将游戏视频画面中局部重点区域如中心战斗区域精细化从而优化视频码率。虽然边缘画面可能会出现一定劣化,但只要用户视觉重点范围内的画面保持清晰,对用户体验的影响非常之小。

2)码率控制算法优化

这一步的优化主要针对线上教育应用场景。其中最重要的元素之一是老师的板书,我们需要确保观看视频的学生可看清老师在黑板上书写的内容。上课时学生的注意力会集中在老师书写的文字区域,除了规范文字书写之外我们也可通过一些可使文字更加清晰的前处理手段提升板书清晰度。从编码角度而言就是将文字用更小的量化步长精细化编码,从而大大提升老师学生使用在线教育产品的用户体验。

我们一直在努力改进码率控制算法的优化,针对码率控制算法的优化有多种,包括机器学习在内的方法都可用于优化码率控制算法。上图列举了一种较为经典的码率控制算法,通过SATD与模糊复杂度计算qscale,而后经过qscale除以rate actor与qscale乘以overflow两次计算,最终得出QP。这样一套经典的码率控制算法可从容处理诸多场景。因为对传统视频的优化是基于帧展开的,帧与帧之间的时间间隔均匀,故对于一般视频会采取平均分配码率的策略;而在实时通讯应用场景中帧和帧之间的时间间隔并不均匀,在此情况下渲染画面时为每帧都平均分配同样的码率显然是不合理的,因此实时通讯应用场景下的码率控制仍需进一步优化。我们曾探索通过调整复杂度、两帧之间的间隔等并寻找更好的解决方案,后来我们发现调整分配码率可实现目标效果。通过多种方式探索不同分配码率的方式,关于这一点仍需继续探索。

Just Noticeable Difference

Just Noticeable Difference是指最小可视差,就像人手无法准确区分两个差距几克的苹果一样,我们身体的感官如视觉系统对每种信号的接受程度不一,刺激有效的阈值也不同,只有当信号刺激达到一定阈值之后我们才能够对其作出反应。如果将这个道理过渡到码率分配,我们可采取为视频中那些有效刺激阈值较高人眼不易察觉的视觉元素分配较少码率,而为那些有效刺激阈值较低人眼可敏感察觉的视觉元素分配更多码率的策略调整码率分配,即可实现人眼无法察觉的有效码率控制算法优化,提升用户体验。

软编码与硬编码

讲到这里,我想大家会有一些疑问:软件编码与硬件编码究竟存在什么区别?在编码模块上,软件编码主要是在CPU上进行而硬件编码则主要在GPU、VPU、DSP、FPGA等多种硬件编码模块上进行;虽然硬件编码的速度明显快于软件编码,但软件编码的质量好于硬件编码是业界公认的事实;除此之外,软件编码相对于硬件编码硬件在功耗上更大,这主要体现在用户使用手机长时间看视频会感受到明显手机发热;带宽要求是指一些编码器会对带宽下降进行要求,例如苹果的编码器会限制视频质量的最低水平,一旦码率过低或质量过差编码器则拒绝编码输出。但对于实时通讯而言,带宽的未知变化使得我们无法准确判断什么时候码率会降低到无法编码的低值,因此硬件编码器在处理实时视频方面存在一些限制;至于GOP结构,软件编码器的GOP结构相对更灵活而硬件编码器的相关参数是固定不变的;参数调整响应方面,软件编码在参数调整下达之后会从下一帧开始迅速响应而硬件编码则需要一定过程才能做出响应甚至需要重启进程;最后在可移植性与可维护性方面,由于不同平台的软件编码都是基于一套代码,无论是维护还是移植成本都较低,而硬件编码由于牵扯到硬件适配的工作,无论是可移植性还是可维护性都逊于软件编码。

3)软硬件编码动态切换

那么应该选择哪种编码方案?在选择软件编码还是硬件编码方案上,我们应当参考以下几个维度做出正确判断:第一个是设备平台,也就是移动端、PC端等。如果是PC端,由于PC的CPU性能足够强大,我们更倾向于选择软件编码,而如果是移动端则需要综合移动端设备的处理器性能等硬件参数择优选择;第二个是CPU负荷,CPU除了需要处理编码工作之外还需处理其他必要任务,如果CPU当中的采集、渲染、前处理等模块在工作时占用了CPU的大量资源并且难以对其进行调配优化,那么我们就需要考虑一下使用硬件编码方案从而降低CPU的工作负荷;第三个维度是设备剩余电量,如果设备剩余电量十分充足那么软件编码对手机续航造成的压力并不大。而如果手机电量岌岌可危则选择硬件编码方案可适当减轻编码过程对手机续航的影响。除此之外还有目标码率、帧率、分辨率、丢包率等参考维度,我们需要综合以上维度选择适宜的动态编码方案。

2.3 后处理——超分辨率

超分辨率属于后处理流程,其好处是可在不理想带宽条件下发送分辨率较低的视频流,而后再借助超分辨率技术提升其分辨率从而在保证视频观看体验的前提下避免网络拥塞与网络丢包。除此之外,超分辨率技术也能够在帮助节省带宽的同时通过提升单位传输帧数提高视频流畅程度,明显提升实时通讯的用户体验。

3. 视频质量评分系统

视频质量评分系统主要用于判断画面质量的优劣,其客观标准主要为MSE、PSNR、SSIM;视频质量评价基于单张图片并依赖原始码流完成,在主观一致性上存在缺陷。

传统判断视频质量的方案是在一定帧率下选取多张图像并取其质量平均值,这样的合理之处在于视频本身是多张图像的合集,但不合理之处在于视频不单单是多张图像的合集,还存在每帧图像时间长短等变量的影响,下图展示的是传统图像质量指标和主观一致性方面的差异:

第一张图是原画而后五张图是加入了不同噪声的效果。这种处理是基于均方差完成的,而传统的视频质量评价方案只会察觉到两张图之间的差距,如果我将均方差调成一致那么虽然系统判断画面质量优良但用户的主观感受一定是非常糟糕的。检验结果与主观一致性的差距,迫使我们需要对视频质量评分系统作出进一步优化。

而VMAF则可有效避免以上情况的发生,其优势在于VMAF通过视觉信息保证度、细节丢失指标、延时码率、运动量等多种维度更全面地评判视频质量。其关键部分是加入了运动量计算,也就是计算两帧之间均方差大小并将其作为影响视频质量的因素之一,均方差越小则视频质量越高;如果两帧之间差值越大,运动量越大,那么视频质量就相应越低。

上图展示的是DMOS视频质量测试算法的拟合曲线,从这些客观指标我们可以看出传统视频质量评价方案的主观一致性较低而VMAF则表现得更好。在这里需要强调的是,如果原画本身进行了质量增强或者其它参数调整,那么得出的视频质量指标一定是不客观,不准确的。因此我们不能将通过VMAF等视频质量评价方案得出的结果作为判断视频质量的唯一标准。

因此就需要建立一套视频质量主观标准。我们的主观评判标准分为画面清晰度、质量平稳度、视频内容、观测条件、视频流畅度五个方面。其中,平衡画面清晰度与视频流畅度是我们努力实现平衡的两项指标,而质量平稳度是指在变化的网络带宽下保证视频质量在一定可接受的范围内波动,而非大幅度的质量突跃或陡降;观测条件则是一项受多重因素影响的指标,如终端屏幕质量、性能等都会对其产生影响,也许在一块1080p屏幕上播放720p视频所带来的用户体验会明显优于在一块720p屏幕上播放1080p视频所带来的用户体验;视频内容同样与用户体验息息相关,但很难为这一指标确立统一的标准,例如使用同样的帧率与分辨率展现一段连续的激烈打斗戏和另一段穿插了感情戏的激烈打斗戏,也许用户会疲于观看快速、模糊的打斗场面抑或是更喜欢凌厉的影像风格,这给用户带来的感受一定是不同的。

4. 未来编码器

大家知道AV1已经成为现实,就现在看来虽然AV1在压缩效率上十分出色,但其较高的复杂度限制了自身的应用场景。也许这种复杂程度对视频点播等实时性要求并不高的应用场景而言尚可接受,但对实时通讯而言,高复杂度一定是需要尽可能避免的;而H.266(VCC)等还需时日,我们拭目以待。

VVC相对于HEVC有50%的提升,大约在2021年可实现硬件级Codec,而First or Final Standard最早会在2019~2020年公开。我们并不需要热衷于追赶潮流,我们需要做的是将Codec打磨好,使其能够以良好性能用于实时通讯网络提升用户体验,毕竟良好的用户体验才是我们努力完善的终极目标。

精品文章推荐

技术干货:

  • Pixel 3的超分辨变焦技术

  • 冯迅:YY多媒体实时传输系统演进

  • 语音编解码技术演进和应用选型

  • 使用级联SFU改善媒体质量和规模

  • 英特尔QSV技术在FFmpeg中的实现与使用

人物专访:

  • 一切从用户的需求与体验出发

  • 雷辉:让视频会议conferencing like TV

  • 梁俊斌:音频技术可以延展众多应用场景

  • 吴晓然:实时通信需要Codec和网络模块结合

基于QoE的实时视频编码优化:低功耗,低延时,高质量相关推荐

  1. SEO优化入门之寻找高质量的友情链接

    SEO优化包括寻找友情链接,友链的交换不仅仅是给网站带来流量,也是网站内容优化的一个选择.友情链接是指互相在自己的网站上放对方网站的链接.必须要能在网页代码中找到网址和网站名称,而且浏览网页的时候能显 ...

  2. 浅析SEO网站优化的三点高质量外链优化技巧

    网站就是企业品牌的形象,无论是大型还是小型企业网站都是想让网站获取更多的用户流量,进而转化为效益.很多网络优化小白在这方面很容易忽略掉外链的建设,更不理解外链到底有什么作用.但是对于网站来说,打造高质 ...

  3. 基于OBS如何实现毫秒级超低延时直播

    原创教程 / 2021-11-16 / 文章字数2300 文章简述:本文介绍使用OBS无延迟直播插件在第三方云平台,如何实现超低延时直播的完整教程(延迟约为400毫秒,通常延迟是3-15秒). OBS ...

  4. 基于realgbs的GB28181接入设备的超低延时web无插件直播

    现在GB28181的平台很多,但是能够实现GB28181接入设备的web无插件超低延时的直播确实不多,或者叫没有.有的小公司甚至直接使用开源的工具去实现GB28181转webrtc的直播,前期技术调研 ...

  5. 基于4G网卡和树莓派zero实现低延时数字图传(250-300ms左右)

    方案本身并不复杂,都是采用成熟的产品,只需要几个命令行就能解决问题 0.准备工作 硬件: 树莓派zero 4G网卡 linux台式机/笔记本/虚拟机 软件: raspivid netcat / nc ...

  6. 详解低延时高音质:回声消除与降噪篇

    在实时音频互动场景中,除了我们上一篇讲到的编解码会影响音质与体验,在端上,降噪.回声消除.自动增益模块同样起着重要作用.在本篇内容中我们将主要围绕回声消除和降噪模块,讲讲实时互动场景下的技术挑战,以及 ...

  7. 支持8K播放且低延时高并发全功能的流媒体播放器如何降低直播延迟?

    背景 直播行业大火,大家可以在日常生活中接触到各类直播,例如游戏直播.乐秀.在线教育.发布会等.无论哪种类型的直播,延时是直播过程中需要关注的重要方面.直播实现低延迟,是对大部分直播产品的要求,低延迟 ...

  8. 低延时高RTSP兼容的EasyPlayer-RTSP-win解决H.264一帧多个nal单元录像花屏问题方案

    我们来讲解一下关于H264编码格式中的一帧多nal(Network Abstract Layer, 即网络抽象层),关于H264和NAL,这里引用一段话来科普一下: [转] 在H.264/AVC视频编 ...

  9. 支持8K播放,低延时高并发流媒体音视频播放器EasyPlayer.js是如何实现播放8K视频的

    需求分析 一般对于一个播放器,应该支持如下几种显示模式: 等比例,最大化区域显示,不裁剪 等比例,最大区域显示,裁剪 拉伸显示,铺满全屏 要实现这几种显示模式.其实只要对播放控件的布局进行些许调整即可 ...

最新文章

  1. CSS中的趣事之float浮动
  2. Beaglebone Back学习七(URAT串口测试)
  3. arm9 6410   tslib触屏小程序
  4. 金蝶mysql_金蝶财务软件中的数据库如何进入?
  5. VTK:vtkCaptionWidget用法实战
  6. 【Flask】Nginx+Gunicorn+Supervisor部署一个Flask项目:步骤总结
  7. UIActivityIndicatorView、UIProgressView 活动与进度指示器 (实例)
  8. mybatis 大于_真赞!IDEA中可以这么玩MyBatis,让编码速度飞起!
  9. HighCharts:隐藏最下方logo
  10. C++ std::vector 自定义排序
  11. Exchange Server 2013文档系列之四: Exchange Server 2013在Windows 2008 R2下部署
  12. 基于SpringBoot的宠物医院管理系统
  13. 写给两个月前的自己的一封信
  14. Java集合判空/非空
  15. Flash Builder常见菊紧问题集锦
  16. 加速PG中vacuum
  17. vue 水印插件 插件:directives.js
  18. CSDN目录有什么用,怎么使用csdn的目录,csdn目录怎么生成?
  19. Java总结13 Lambda表达式 和 方法引用 的概念与应用
  20. leetcode【135】Candy【c++版,双数组,单数组,坡峰坡谷】

热门文章

  1. 反射和代理的具体应用
  2. 远程管理,无需在机房来回穿梭
  3. JProfiler9安装 监控Tomcat
  4. Webserver推送技术
  5. Java序列化简单例子
  6. AIX性能管理指南-luoqiangb@dc
  7. contentwindow无法搜索对象_面试官:讲一下Jvm中如何判断对象的生死?
  8. 让软件不在添加删除程序_功能强大却鲜为人知的四款软件,一但发现就无法自拔...
  9. 【数据结构】集合及运算
  10. 51nod---无法表示的数