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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/84949360

640?wx_fmt=jpeg


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


文 / 吴晓然

整理 / LiveVideoStack


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


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


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


640?wx_fmt=png


1. 实时视频通讯的QoE


640?wx_fmt=png


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


640?wx_fmt=png


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


640?wx_fmt=png


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


2. Agora的探索与实践


640?wx_fmt=png


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


640?wx_fmt=png


2.1 前处理


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


640?wx_fmt=png


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


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


640?wx_fmt=png


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


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


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


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


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


2.2 编解码


1)区域检测及ROI编码


640?wx_fmt=png


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


2)码率控制算法优化


640?wx_fmt=png


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


640?wx_fmt=png


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


Just Noticeable Difference


640?wx_fmt=png


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


软编码与硬编码


640?wx_fmt=png


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


3)软硬件编码动态切换


640?wx_fmt=png


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


2.3 后处理——超分辨率


640?wx_fmt=png


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


3. 视频质量评分系统


640?wx_fmt=png


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


640?wx_fmt=png


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


640?wx_fmt=png


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


640?wx_fmt=png

 

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


640?wx_fmt=png


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


640?wx_fmt=png


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


4. 未来编码器


640?wx_fmt=png


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


640?wx_fmt=png


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


精品文章推荐






技术干货:



人物专访:


猜你喜欢

转载自blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/84949360