在浏览器中分析AV1码流

与Google、苹果和微软不同，Mozilla的Firefox并没有庞大的生态系统照看和支持。不过这并不能妨碍Firefox Quantum取得广泛的好评。Firefox的拥趸疯狂的支持这家拥抱开源、开放的科技公司。Mozilla也是AV1和WebRTC重要贡献者，在LiveVideoStackCon 2018大会上，Google多媒体组的Zoe Liu称赞了Mozilla的贡献。作为下一代免专利费、开源的编解码器，AV1被认为将给互联网上的多媒体开发和应用带来广泛影响。本文来自Mozilla研究主管Michael Bebenita，他在浏览器上实现了视频流分析，帮助Codec开发人员快速分析性能，定位bug。LiveVideoStack进行了摘译，点击『阅读原文』访问原文链接。如果你有兴趣利用业余时间为LiveVideoStack贡献，欢迎申请成为的社区编辑，你可以通过LiveVideoStack微信公众号内回复『社区编辑』了解详情。

在Mozilla，我们一直在努力研究新一代AV1视频编解码器。AV1可比HEVC（H.265）和Google VP9提高25％的编码效率，并由AOM开放媒体联盟（ Mozilla & ATEME都是是其一部分）开发。

AV1事实上是VP9的衍生产品，现在还包括大量额外的编码工具需要从Daala、Thor和VP10编码导入进行测试实验。这些实验以意想不到内容形式和画面复杂性产生互相作用，必须在各种各样的画面内容上反复测试，这可是很花时间的。单个视频帧有时可能需要一个多小时的时间才能完成编码，而且这只不过是我们日常测试的一小部分而已，我们编码30个视频剪辑，每个剪辑包含60帧。整个编码过程是大规模并行的，并在AWS上运行，虽然使用了硬编码，运行一个测试任务仍然可能需要几个小时甚至几天之久。

遗憾的是这种计算成本使得开发者不便于本地编码和分析视频流，但也揭示了一个有趣的现象。为什么不在云（或浏览器）中运行我们所有的分析工具呢？

我们的第一个尝试就是使用流分析仪。分析仪解码AV1数据流并显示关于流信息的各种细节。这些信息可以帮助编解码器工程师更轻松地识别和修正bug。分析仪的输入通常很小（一个编码比特流），但输出流非常大。例如：一个1080p的视频帧产生4MB的原始图像数据和大量的分析元数据。如果分析仪在本地运行，简直小意思，但是若是分析仪在远程服务器上运行，则带宽尤其是延迟会很致命。

理想的解决方案是直接在浏览器中运行分析仪。为此，我们需要将分析器和编解码器移植到JavaScript中（幸运的是要感谢Alon Zakai，为我们提供一个工具Emscripten可以帮助我们），并在浏览器中运行它。

分析器由两个组件组成：decoder.js，它是编解码器的Emscripten编译版本和基于HTML的UI前端。要分析一个视频，我们只需要指定一个视频文件（采用* .ivf格式）和一个适当参数的decoder.js文件来解码它。

代码语言：javascript复制

analyzer.html?decoder=decoder.js&file=a.ivf&file=b.ivf

在上面的链接中，analyzer.html加载解码器，并用它解码2个码流a.ivf和b.ivf。或者也可以使用多个解码器来分析视频：

代码语言：javascript复制

analyzer.html?decoder=aDec.js&file=a.ivf&decoder=bDec.js&file=b.ivf

这种方法的优点在于你可以轻松共享链接到解码的视频，而且所有这些都在浏览器中运行，无需维护任何服务器基础架构。对于提交给AreWeCompressedYet.com（AWCY）的编解码器的每个修订版，都会自动生成解码器JavaScript文件方便它们可公开访问。

你可以按照以下步骤实现：

参考这里：http://aomedia.org/contributor-guide （如果你想帮忙，我建议你参照这样做）
查看与要分析的编码视频兼容的编码解码器的特定修订版本。
构建并运行假想的本地分析程序。
如果你想分享一些分析结果，截图并分享，或者要求同时重复第1步到第3步。当然，他们不太可能这样做，因为它不止一次点击那个文档。

也许我是在一家浏览器公司工作，所以我可能会有偏见，但我认为这是最好基于网络分析方式。

Emscripten通常用于将游戏或C / C 库移植到网络上，这实际上并没有什么大不了，但如有稍微的差别也许是我从未测试过而已哈。我们使用Emscripten来使我们的持续集成构建控件可运行和可分享，这是有多酷？超便利打败本地分析！！

玩转分析器

所以让我们用码流分析来看看，下面我们将比较这两个流：crosswalk_10.ivf和crosswalk_60.ivf。这两个视频采用相同版本的编码器进行编码，分别为10和60 QP（数量越少，质量越高）。分析器将块的细节可视化为一组叠层来观察。

人行横道第1帧@10 QP

人行横道第1帧@60 QP

块拆分层

AV1中的最大块大小为64x64，最小为4x4。（有实验说可以扩展这个范围。）编码器使用大量的因素来决定如何递归地划分64x64块。但总的来说，我们可以从下面的图片中看到，细节更多的区域的块大小更小，细节更少的区域的块大小更大。在质量较低的设置中，平均块大小比较大些，但只适用相同的一般情况下。块的大和小很重要，因为这是编码器跳过信号信息，运动矢量，预测模式，变换类型和其他类型信息的水平。块尺寸越小，编码器可以发送的信息越多，但这也意味着编码器会消耗更多的比特位来显示这些细节。

块拆分情况-人行横道第1帧@10 QP

块拆分情况-人行横道第1帧@60 QP

视频的第一帧是一个帧内帧（Intra-frame coding），这意味着每个块是从它周围的块（从上至下）在空间上进行预测的。视频的第二帧是一个帧间帧，这意味着它是从帧之前（或之后）的帧中暂时预测的。对于第二帧（下面）的块拆分决定是有趣的，它们只反映在两个帧之间变化的图像区域。前景中两个人的头向右平移，所以改变的区域围绕头的轮廓。面部虽然向右移动，但不需要细颗粒度的块，因为它可以从前一帧粗略地预测，而头部周围的区域反而不能。

块拆分情况-人行横道第2帧@60 QP

分析可以将每个块大小所覆盖的区域绘制成堆积条形图。第一帧是这个视频序列是唯一的，因为它是一个帧内帧。它使用大致相等数量的16x16,32x32,64x64块。其余的帧都是帧间帧数，大部分使用64x64块。有趣的是，这里有一个反复出现的现象。第8帧、16帧、24帧块中似乎没有32x32块。我很想知道为什么？这些应该分析器要发现的问题。这有可能是编解码器的正常操作行为，也可能是一个错误导致。

块拆分情况 - 人行横道画面，共32帧@ 60 QP

在10QP，这看起来不同，但有点类似。

块拆分情况 - 人行横道画面，共32帧@ 10 QP

预测模式层

每个块都有一个预测模式。对于内部帧，这些包括定向预测模式，在每个块内绘制为细线。彩色块使用DC_PRED（粉红色）和TM_PRED（蓝色）。

帧内预测模式 - 人行横道画面，第1帧 @ 60 QP

如果通过点击中心来放大中心女士的眼睛，我们可以清楚地看到这些编码决策最终产生的预测模式和编码伪像。如下图

帧内预测模式 - 人行横道，第1帧 @ 60 QP

帧内预测模式伪影 - 人行横道，第1帧 @ 60 QP

帧间帧没有方向预测模式：白色（NEWMV），蓝色（NEARMV），紫红色（NEARESTMV）和紫色（ZEROMV）。

国际预测模式 - 人行横道画面，第2帧 @ 60 QP

块信息详细信息

您可以通过点击获得有关块的更多信息。例如，点击左上方的紫色块（0x0）显示以下块详细信息

这是方便的方法来弄清楚什么颜色的意思。

运动矢量图层

帧间的块可以从其他帧预测。每块可以有2个运动矢量在这里显示为红线和蓝线的组合。颜色的强度代表矢量的大小。每个矢量都是可以预测块内容的偏移量。矢量越长，运动就越多。

运动矢量 - 人行横道画面，第2帧 @ 60 QP

位统计层

在AV1中，无论何时从比特流中读取符号，解码器都跟踪用于表示该符号的比特数。位记帐信息具有块级上下文，这意味着分析器可以确切地确定在每个符号类型的块上花费了多少位。在下表中，该位计费信息被聚合在整个帧上：458个read_mv_component符号采样被读取，总计537比特或28.5%的量用于对帧进行编码。