共计 4361 个字符，预计需要花费 11 分钟才能阅读完成。
本文为 「Dev for Dev 专栏」 系列内容，作者为声网资深视频算法负责人 戴伟。
01 视频编解码规范的历史和当初
1990 年左右 H.261 规范的制订，开启了视频编解码标准化的历程。通过 30 多年的致力，视频的编码效率失去了极大幅度的晋升。在下图中，咱们大抵列举了一下所有的视频编码标准的制订组织和公布工夫。
咱们能够发现，到目前为止，视频编码畛域次要还有三大组织在制订规范。他们别离是制订 H.26x 系列的编解码规范的 ITU-T 和 MPEG 联结的组织，制订 Avx 系列的编解码规范的以 Google 为首的 AOM 联盟以及制订 AVSx 系列的编解码规范的中国专家组。
在这些规范中，目前世界上利用最为宽泛的规范，是 ITU-T 和 MPEG 联结制订的 H.264、H.265 以及 Google 制订的 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 的时代下，又涌现出了哪些新的需要呢？
02 RTE 时代下对编解码规范提出新的需要
RTE 里的视频利用场景和一般利用场景最显著的区别，在于对视频的端到端延时要求。一般的视频点播因为没有互动的需要，所以根本不关注延时的问题。而 在 RTE 场景中通常会波及到大量的交互与互动，因而对延时有着极高的要求，个别要求至多是在 300ms 以内。并且因为超低延时的限度，导致编码的输入码率对网络带宽的变动要更为灵活。
另外，因为 RTE 是实时的利用场景，所有产生的视频能够认为是即编即用的，这也是和一般视频场景的一个极大区别。因为在一般的视频场景中，视频的播放次数远远大于视频的压缩次数，这也是所有编解码规范中尽力管制解码器复杂度的起因。而在 RTE 的畛域，如果不思考非凡的录制等需要，所有的视频都是编码一次，播放无限次的。
在这两个大前提下，视频的编码和传输在 RTE 的畛域里就催生了几个很重要的问题：
1、在码率稳定的状况下如何保障画质的稳固
在传统的视频编码的场景中，个别是先给定一个固定的码率，而后整个视频以这个不变的码率作为指标进行编码。在这种场景下，编码器能够绝对容易的管制整个视频画质的稳固。然而在一个实时传输的零碎中，网络带宽是实时变动的，可能前一秒还是一个通顺的网络情况，下一秒就因为网络拥塞而导致指标码率突降。
例如咱们当初正在以 1.2Mbps 的码率编码一个 720P 15fps 的视频，忽然因为网络的起因，以后可用的带宽降落到了 300kbps，此时，如果编码器仍然还以 720P 15fps 的形式去编码这个码流，会体验到十分重大的主观画质降落的问题。
另外，在带宽稳定的状态下，如何保障画质的安稳适度，也是一个十分重要的问题，当带宽从 1.2Mbps 突降到 300kbps，而后又缓缓俯冲回 1.2Mbps 的时候，如何保障这期间画质的稳固，也是对用户体验的一大考验。
2、如何在丢包的状况下保障视频的晦涩度
在传统的互联网点播场景中，个别都会有 2 – 3 秒的播放缓存工夫。如果遇到网络丢包的状况时，延时可能会到 5 秒以上。这些延时在真正的观看体验中除了提早变大的那一刻，其余时候根本是无感知的。然而，在 RTE 的场景中，因为有着实时互动的要求，对端到端的延时有着极高的要求，过高的延时会间接导致应用体验的好转。
在低延时的前提下，解码器并没有太多的工夫来期待传输过程中失落的包。所以在丢包率较高的场景下，很容易呈现有几帧，甚至间断几帧无奈在接收端残缺收到的状况。如果没有一个很好的抗丢包的策略，那么很可能后续的视频帧都会因为找不到对应的参考帧而无奈解码。
为了让视频可能从新解码，个别须要编码器从新发一个 IDR 帧。而 IDR 帧因为能够独立解码，不依赖后面的帧是否可解，导致他的帧大小是个别的 P 帧的 2 – 3 倍以上。这么大的帧在丢包率较高的网络条件下，会有更高的概率无奈被残缺的收到，进一步加剧视频的卡顿率，导致较差的用户体验。
3、如何晋升低码率下的视频品质
RTE 场景中挑战性最大的就是如何在弱网场景下仍然保障不错的用户体验。在传统的编解码规范中，当给定码率很低的时候，只能通过应用一个很大的量化步长来尽可能的抛弃图像信息来达到低码率的目标。然而这种做法会引入很重大的块效应，极大的影响了咱们的主观体验。
在 RTE 的场景中，咱们能够通过一系列的办法来晋升主观的画质。在发送端能够有包含降帧率、降分辨率等办法，其中降帧率并不需要重启编码器，而降分辨率则个别须要重启整个编码器，抛弃掉之前的所有编码信息。在接收端则能够通过超分等办法进行画质的图像晋升等。
然而这些办法在码率特地低，QP 特地大的时候，都无奈很好的将损失的画质给补救回来，反而可能会引入额定的主观画质问题。例如超分的画面如果有这很重大的块效应，那么超分进去的画面会在很大水平上仍然保留这些块效应的边界，甚至可能会在在这些边界上引入更重大的 artifacts。
03 新编解码规范的技术瞻望
在说了这么多 RTE 场景下对视频编解码的新需要之后，咱们再来谈一谈这些新需要会促生视频编解码的一些什么新的技术瞻望。
1、动静分辨率适配
在传统的编解码规范中，一旦编码开启，整个过程中的分辨率是不能变动的。如果想变动分辨率，有几种办法能够抉择：
①应用多条流编码不同分辨率，并且在对应地位进行流切换的形式来达到分辨率变动的目标。
②应用 SVC 技术来进行动静分辨率的切换。
两种办法比拟起来，咱们能够看到办法①的架构比办法②要简略很多，整体的业务逻辑也会绝对简略清晰。
然而因为办法①的多条流之间是相互独立的，所以在上行发送的时候，这些流会占据较多的上行码率；办法②里因为流是相互依赖的，所以它的上行码率比办法①起来会少一点。然而，对于接收端来说，如果接收端观看的都是小分辨率的视频，那么两个计划对于接收端来说没有区别。然而如果接收端观看的是大分辨率的视频，那么办法②的总体码流因为流之间的信息冗余，会比办法①的单流要高出 10% 左右的码率。
所以上述两种办法，都有各自的优缺点。而咱们所说的动静分辨率适配技术，即在编码过程中动态变化编码的分辨率，而后再解码的时候通过上采样的技术全副都采样到雷同的分辨率，很好的排汇了前两种办法的长处。咱们能够发现，在 AV1 中曾经提出了一种编码过程中超分辨率的办法。即在编码 1280x720P 的时候，如果遇到带宽等问题须要升高分辨率进行编码，它会以 640x720P 的分辨率来编码以后帧，而后再解码的时候再通过一个确定的形式将画面超分回 1280x720P。
AV1 的这个设计，过后是思考到硬件缓存的限度，所以只在程度方向进行缩放，垂直方向并没有进行缩放。
然而，仅仅程度方向的二分之一的缩放，对降低码率并不能起到十分大的作用，未来的编码器应该能够反对更多方向，更大比例的缩放，来达到动静降低码率的指标。
2、可配置的 in-loop filtering
传统的编解码规范里只规定了解码的整个流程，包含流程中用到的各种系数，都用一个文档规定的非常明确。这么做的次要目标，是在于确保无论什么时候，什么设施编码进去的码流，只有合乎这个规范，都能够随时随地被依照这个规范设计的解码器正确解码进去。实质上，它还是为了编码一次解码无数次的目标而设计的。这种设计办法有一个比拟显著的问题，即他们的 in-loop filtering 的可调参数太少了，不能在所有的场景下失去最优的成果。
在 RTE 的场景下，咱们其实并不需要思考太多一个小时后他人想看的话怎么办这种问题，咱们更须要关注的是在互动的过程中如何失去最佳的用户体验。那么咱们就能够将这些滤波的系数都改成可配置的。例如在户外场景咱们能够应用一套专门为了户外训练的模型，在室内场景咱们能够应用一套专门为了室内训练的模型，屏幕共享的时候应用一套专门为了字体优化过的模型。甚至在当前遇到新场景时，再训练一套这个新场景下的模型。
更进一步说，咱们能够将和编解码相干的后处理，作为一个新的 in-loop filtering 模块，做到编解码的流程中去。这样就能够进一步晋升参考帧的品质，晋升压缩的效率。
这样的话，咱们就能够在各种各样的场景下，失去更佳的用户体验。
3、更适应网络的丢容纳错机制
在传统的视频编解码规范的制订过程中，并没有思考过太多的各种网络丢包时如何进行谬误复原的形式，也并没有规定进行谬误复原的形式和办法，而是把这个能力交给了每一个开发者来定义。这个在某种程度上为开发者提供了十分大的谬误复原计划的灵活性，然而这么做的代价，就是所有的谬误复原都是只能在解码之后能力进行操作。从另外一个角度来说，也限度了编码器取得更高编码效率的空间。所以在 RTE 的场景中，咱们须要一套 in-loop error concealment 的办法，来最大化的晋升编码效率。
此外，在 syntax 的层级，传统的视频编解码算法也并没有什么非凡解决的办法，咱们还须要再 syntax 的档次对网络的丢包场景进行进一步的适配，充分考虑各种丢包的状况进行解决，达到最高的编码效率。
04 总结
在 RTE 的利用越来越宽泛的明天，因为 RTE 的场景有其非凡的要求，传统的编解码规范不可能很好的适应 RTE 的场景的要求。咱们置信随着 RTE 的利用越来越宽泛，那么新的编解码规范在制订的时候，就不可避免的须要思考 RTE 的新需要，发明出一个新的 RTE 的视频编解码规范。
（注释完）
对于 Dev for Dev
Dev for Dev 专栏全称为 Developer for Developer，该专栏是声网与 RTC 开发者社区独特发动的开发者互动翻新实际流动。
透过工程师视角的技术分享、交换碰撞、我的项目共建等多种形式，汇聚开发者的力量，开掘和传递最具价值的技术内容和我的项目，全面开释技术的创造力。
