当前位置: 首页 > Web前端 > HTML

RTE的发展给视频编解码标准带来了哪些新变化?丨DevforDev专栏

时间:2023-03-28 12:03:30 HTML

本文为“DevforDev专栏”系列文章,作者为声网高级视频算法负责人戴威。01视频编解码器标准的历史和1990年前后H.261标准的制定,开启了视频编解码器标准化进程。经过30多年的努力,视频的编码效率有了很大的提高。在下图中,我们大致列出了所有视频编码标准的制定组织和发布时间。我们可以发现,到目前为止,视频编码领域仍然有三大组织在制定标准。他们分别是制定H.26x系列编解码标准的ITU-T和MPEG联合组织,制定Avx系列编解码标准的以Google为首的AOM联盟,以及制定H.26x系列编解码标准的中国专家组。AVSx系列。在这些标准中,国际上使用最广泛的标准是ITU-T和MPEG联合制定的H.264和H.265,以及谷歌开发的VP9和其后的AV1。其中,H.264已有近20年的历史,其编码效率远低于H.266等最新的编解码标准。但是,由于其设备范围极其广泛,它仍然是支持最多的一种。编解码器标准。下图是Bitmovin连续4年进行的编解码器使用问卷调查。我们可以发现,除了H.264之外,H.265也是支持度比较高的编解码标准,VP9和AV1也有一定的增长势头。一般来说,H.26x系列的编码标准由于有广泛的公司参与和支持,硬件芯片会更容易实现。不过自H.265之后,不明朗的专利费也成为了他们推广的一大障碍。相反,AV1从制定之初就设定了免专利费的目标,并在研发过程中得到了越来越多企业的支持和参与。我们相信对AVx系列的支持将继续以惊人的速度发展。视频编解码器标准的首要目标是在保证图像质量的同时尽可能压缩视频文件大小,节省存储和传输成本。这个目标也很适合最初使用视频的,也就是一开始的VCD和DVD,以及后期互联网兴起后的视频点播网站。但是随着RTE的不断发展,视频领域也出现了很多新的需求,而这些新的需求又会反过来推动编解码器的进一步发展。那么,在RTE时代,出现了哪些新的需求?02RTE时代对编解码标准的新要求RTE中视频应用场景与普通应用场景最明显的区别在于对视频的端到端时延要求。普通的视频点播因为不需要交互,基本不关注延迟的问题。在RTE场景中,通常会涉及到大量的交互和交互,因此对时延有着极高的要求,一般要求至少在300ms以内。并且由于超低延迟的限制,编码后的输出比特率对网络带宽的变化更加敏感。另外,由于RTE是一个实时的应用场景,所有生成的视频都可以认为是即用型的,这也是与普通视频场景的一个很大的区别。因为在普通的视频场景中,视频的播放次数远大于压缩次数,这也是所有编解码标准都想方设法控制解码器复杂度的原因。在RTE领域,如果不考虑特殊录制等需求,所有视频都编码一次,播放次数有限。在这两大前提下,视频的编码和传输催生了RTE领域的几个非常重要的问题:1.如何在码率波动的情况下保证画质的稳定性在传统的视频编码场景中一般来说,先给定一个固定码率,然后以这个固定码率为目标对整个视频进行编码。在这种情况下,编码器可以相对容易地控制整个视频质量的稳定性。然而,在实时传输系统中,网络带宽是实时变化的。可能是前一秒网络还畅通,下一秒就因为网络拥塞导致目标码率突然下降。例如,我们目前正在以1.2Mbps的比特率对720P15fps视频进行编码。突然,由于网络原因,当前可用带宽下降到300kbps。这时候,如果编码器仍然以720P15fps编码这个比特流,你会体验到非常严重的主观质量下降问题。此外,在带宽波动的状态下,如何保证画质的平滑过渡也是一个非常重要的问题。当带宽突然从1.2Mbps下降到300kbps,又慢慢爬回1.2Mbps,这期间的画质如何保证?质量稳定性也是对用户体验的一大考验。2、丢包情况下如何保证视频的流畅度在传统的互联网点播场景中,通常会有2-3秒的播放缓冲时间。如果遇到网络丢包,延迟可能会超过5秒。这些延迟在真实的观看体验中,除了延迟变大的那一刻,基本感觉不到。但在RTE场景下,由于实时交互的需求,对端到端的时延要求非常高,过大的时延会直接导致用户体验的恶化。在低延迟的前提下,解码器没有太多时间等待传输过程中丢失的数据包。因此,在丢包率高的场景下,接收端很容易出现几帧,甚至连续几帧没有完全接收的情况。如果没有很好的防丢包策略,很可能会导致后续的视频帧因为找不到对应的参考帧而无法解码。为了让视频能够重新解码,编码器一般需要重新发送一个IDR帧。但由于IDR帧可以独立解码,不依赖于前一帧是否可解码,因此其帧大小是一般P帧的2-3倍以上。这么大的帧在丢包率高的网络条件下,接收不完整的概率会更高,进一步加剧视频卡顿,导致用户体验不佳。3、如何提升低码率下的视频质量RTE场景最大的挑战是弱网场景下如何保证良好的用户体验。在传统的编解码器标准中,当给定的比特率很低时,实现低比特率的唯一方法是使用较大的量化步长来尽可能地丢弃图像信息。但是这种做法会引入非常严重的块效应,极大地影响我们的主观体验。在RTE场景中,我们可以通过一系列的方法来提升主观画面质量。在发送端,有降低帧率和降低分辨率的方法。其中,帧率降低不需要重启编码器,而分辨率降低一般需要重启整个编码器,丢弃之前的所有编码信息。在接收端,可以通过超分辨率等方法提高图像质量。然而,这些方法在码率极低和QP极大时不能很好地弥补图像质量的损失,并且可能引入额外的主观图像质量问题。例如,如果超分辨率图片有这么严重的块效应,那么超分辨率图片仍然会在很大程度上保留这些块效应的边界,甚至可能在这些边界上引入更严重的伪像。03编解码新标准的技术展望说完这么多RTE场景下对视频编解码的新需求,我们再来说说这些新需求对视频编解码带来的一些新的技术展望。1.动态分辨率适配传统编解码标准中,一旦启用编码,全程不能改变分辨率。如果要改变分辨率,有以下几种方案:①使用多路编码不同的分辨率,在相应的位置切换流,达到改变分辨率的目的。②采用SVC技术切换动态分辨率。对比两种方法,我们可以看出方法①的结构要比方法②简单很多,整体的业务逻辑也会比较简单明了。但是由于方法①中的多个流相互独立,所以这些流在上行发送时会占用更多的上行码率;方法②中,由于码流相互依赖,其上行码率比方法①高一点。但是对于接收端来说,如果接收端看的都是小分辨率的视频,那么对于接收端来说两种方案没有区别。但是,如果接收端是看高分辨率的视频,由于流间信息的冗余,方法2的整体码率会比方法1的单流高10%左右。因此,以上两种方法各有优缺点。所谓动态分辨率适配技术就是在编码过程中动态改变编码分辨率,然后在解码时通过上采样技术将所有样本采样到相同的分辨率,很好的吸收了前两种分辨率。这种方法的优点。我们可以发现在AV1中已经提出了一种在编码过程中进行超分辨率的方法。即在编码1280x720P时,如果遇到带宽等问题,需要降低分辨率进行编码,它会将当前帧编码为640x720P的分辨率,然后在解码时,将画面超分回到1280x720P以某种方式。AV1的设计考虑到当时硬件缓存的限制,所以只在水平方向缩放,垂直方向不缩放。但是,水平方向上只有一半的缩放对于降低码率并没有起到很重要的作用。未来的编码器应该能够支持更多方向和更大的缩放比例,以实现动态比特率降低。目标。2.可配置的环路滤波传统的编解码标准只规定了解码的整个过程,包括过程中用到的各种系数,在一份文件中明确规定。这样做的主要目的是为了保证无论什么时候,什么设备对码流进行编码,只要符合这个标准,就可以随时随地被按照这个标准设计的解码器正确解码。本质上,它就是为了一次编码,无数次解码而设计的。这种设计方式有一个明显的问题,就是他们的环路滤波可调参数太少,无法在所有场景下都获得最优的结果。在RTE场景下,我们其实不需要考虑太多,别人想晚一个小时看怎么办。我们需要更加关注如何在交互过程中获得最佳的用户体验。然后我们可以将这些滤波器的系数更改为可配置的。比如在户外场景我们可以使用一组专门针对户外训练的模型,在室内场景我们可以使用一组专门针对室内训练的模型,在共享屏幕的时候我们可以使用一组专门针对户外训练优化的模型。字体。甚至以后遇到新场景的时候,在这个新场景下训练一套模型。此外,我们可以在编解码过程中使用编解码器相关的后处理作为新的环内滤波模块。这样可以进一步提高参考帧的质量,提高压缩效率。这样我们就可以在各种场景下获得更好的用户体验。3、更适应网络丢失和错误机制在传统的视频编解码器标准制定过程中,没有考虑太多各种网络包丢失时的错误恢复方法,也没有错误恢复的规定。方式和方法,而把这种能力留给每个开发者去定义。这在一定程度上为开发者在错误恢复方案上提供了极大的灵活性,但这样做的代价是所有的错误恢复都只能在解码后才能运行。从另一个角度来说,也限制了编码器获得更高编码效率的空间。所以在RTE场景下,我们需要一套in-looperrorconcealment方法来最大化编码效率。另外,在句法层面,传统的视频编解码算法并没有任何特殊的处理方式。我们需要在语法层面进一步适配网络的丢包场景,充分考虑各种丢包情况。处理以达到最高的编码效率。04总结在RTE应用越来越广泛的今天,由于RTE场景的特殊要求,传统的编解码标准已经不能很好的满足RTE场景的需求。我们认为,随着RTE的应用越来越广泛,在制定新的编解码标准时必然要考虑RTE的新需求,创建新的RTE视频编解码标准。(文末)关于DevforDevDevforDev专栏名为DeveloperforDeveloper。本专栏是声网与RTE开发者社区共同发起的开发者互动创新实践活动。通过工程师视角的技术分享、交流碰撞、项目共建等形式,汇聚开发者的力量,挖掘并传递最有价值的技术内容和项目,充分释放技术的创造力。每月注册试用10000分钟免费SonicVideoSDK,体验四行代码,30分钟快速搭建沉浸式实时交互场景下载体验Sonic相关demo