与Google、苹果和微软不同，Mozilla的Firefox并没有庞大的生态系统照看和支持。不过这并不能妨碍Firefox Quantum取得广泛的好评。Firefox的拥趸疯狂的支持这家拥抱开源、开放的科技公司。Mozilla也是AV1和WebRTC重要贡献者，在LiveVideoStackCon 2018大会上，Google多媒体组的Zoe Liu称赞了Mozilla的贡献。
作为下一代免专利费、开源的编解码器，AV1被认为将给互联网上的多媒体开发和应用带来广泛影响。本文来自Mozilla研究主管Michael Bebenita，他在浏览器上实现了视频流分析，帮助Codec开发人员快速分析性能，定位bug。LiveVideoStack进行了摘译，点击『阅读原文』访问原文链接。如果你有兴趣利用业余时间为LiveVideoStack贡献，欢迎申请成为的社区编辑，你可以通过LiveVideoStack微信公众号内回复『社区编辑』了解详情。
文 / Michael Bebenita
译 / 蒋默邱泽
在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文件来解码它。
analyzer.html?decoder=decoder.js&file=a.ivf&file=b.ivf
在上面的链接中，analyzer.html加载解码器，并用它解码2个码流a.ivf和b.ivf。或者也可以使用多个解码器来分析视频：
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%的量用于对帧进行编码。
分析器还可以在多个帧中显示聚合的比特信息。 这在比较两个不同的位流时很有用。 这些图表是特地安排的，这样它们在视频之间切换时不会移动，以便更容易发现差别。
数据统计信息也可以作为图层显示。突出显示的紫色区域表示帧内的位层深度分布。
位层 - 人行横道画面，1 帧 @ 60 QP
下图禁用图像使位轮廓计算层更清晰一些
位层 - 人行横道，1帧 @ 60 QP
如果我们进入第二帧，我们将会会看到更明亮的彩色区域。默认情况下，颜色比例和强度是根据帧/像素的最大数量/像素数量来计算的。以下是可调整比例：
相对帧：默认情况下，这在分析单个帧内的位分布时非常有用。
相对视频：在视频序列中的所有帧上计算最大比特数/像素数。这在分析整个序列中的位分布时非常有用。
如果我们看到第二帧，我们会看到它有更亮的彩色区域。这并不意味着它使用更多的数据在里面，这只是意味着帧中的更多的数据量花费在图像的较小区域块。
当然颜色比例也可以调整，默认情况下分析仪使用具有透明度的热点图比例。蓝色大多半透明，红色区域不透明而已。
单色：单一颜色，透明。
热点图：默认情况下，热图与透明度的颜色比例。
位层 - 人行横道画面，2帧@ 60 QP
热点图（不透明）：热图颜色比例没有透明度。
位图层 - 热图不透明情况 - 人行横道，2帧@ 60 QP
位统计层还允许您根据符号类型进行过滤。这对于深入了解特定符号的数据位分布非常有用。例如，下面我们可以看到“read_mv”（读运动矢量）符号的数据位分布。
位图层 - 热图不透明 - 由“read_mv”过滤 - 人行横道，2帧@ 60 QP
跳过标志图层
跳过标志用来表示一个块没有系数。跳过的块被绘制成蓝色，从下面的图片中可以明显看出跳过的块出现在大部分为空的图像区域中。如果我们也覆盖比特核算层，我们可以看到大多数比特花费在非跳过区域，这是可以预判的部分。
下一步还剩什么呢？
Emscripten解码器其实使用起来足够快了，但它可以优化的更快。在高位深度模式下编解码器使用64位计算，需要在asm.js中模拟因为它缺少64位整数计算方式。我所知道影响性能约10%~20%。另一方面WebAssembly支持64位计算，一旦移植没问题我们将切换到WebAssembly。
如你所愿，AV1有大量的SIMD代码路径。至少我们做法是禁用分析器架构中的所有SIMD。
如果您不想在浏览器中测量原始解码性能，你可以试试这个基准测试链接。在我的机器上，Firefox需要512毫秒来解码15帧，Chrome需要719毫秒和Safari更久需要 1044毫秒。
另外一个性能问题是YUV2RGB的转换。这类代码使用浮点计算，需要另外进行优化。
如果你想趁热了解AOM进展请看下面这个视频https://youtu.be/lzPaldsmJbk
LiveVideoStack 2018年春季招聘
LiveVideoStack是专注在音视频、多媒体开发的技术社区，通过传播最新技术探索与应用实践，帮助技术人员成长，解决企业应用场景中的技术难题。如果你有意为音视频、多媒体开发领域发展做出贡献，欢迎成为LiveVideoStack的一员。我们正在招募商务助理，高级编辑，策划编辑，课程经理。
通过job@livevideostack.com联系，或在LiveVideoStack公众号回复『商务助理』，『高级编辑』，『策划编辑』，『课程经理』了解详情。
