这款VP9视频解码器是目前世界上速度最快的同类产品，能够高效处理高质量的视频内容，提供卓越的解码性能和流畅的播放体验。
当Google发布VP9视频解码器的时候我非常兴奋——因为我当时是参与创建它的人之一（我现在已经不在那里工作了）。这个新标准有多好？还能改进到什么程度呢？
为了评估这个问题，我和Clément Bœsch决定从头开始为FFmpeg编写一个VP9解码器。我们的目标与最初ffvp8的情况一样：社区开发的、快速且免费的。
我们还想要回答一些新的问题：一个好的编写的解码器在速度上如何与其他编码格式比较？简而言之（详见下文细节）：作为一项标准，VP9非常令人印象深刻——它在很多情况下都超过了x264。然而，它的编码过程很慢，非常慢。当设置为更高的速度时，质量的提升几乎消失不见。
libvpx单线程解码的速度并不出色。FFvp9比它快了25-50%不等，在各种机器上都有所体现。与ffvp8相比，FFvp9稍显缓慢；但相较于使用相同SSIM得分文件进行编码的ffh264而言，则要更快一些。
多线程性能方面，libvpx的表现不佳——它的loopfilter-mt算法几乎没有任何收益。相比之下，FFvp9在多线程上的增益与ffh264/ffvp8相当，但是有一个上限（受材料、设置和分辨率影响而变化，在我们测试的某些剪辑中大约为15-20%）。
关于ffvp9相对于libvpx-vp9性能的一些观察：
- 在大多数情况下，ffvp9比libvpx快约25%-50%，这意味着使用典型的中高端硬件可以播放4K内容而不会出现问题。然而，低端设备可能难以流畅地播放720P的视频（但使用ffvp9则没问题）。
- Haswell处理器上的性能差距明显小于Sandy Bridge上，这可能是由于libvpx具有针对MC和环路滤波器的一些AVX2优化，而ffvp9尚未进行这些改进；这意味着这种差异在未来可能会随着FFmpeg获得更多AVX2支持而扩大。
- 在Atom平台上，两者之间的区别较小。原因可能在于我们还没有在该平台性能上投入太多努力。Atom处理器具有不同寻常的延迟，在GPR和XMM寄存器之间传输数据时需要特别注意指令排序以避免不必要的停顿——这是我们尚未解决的问题（对于ffvp9而言）。
另外，一些用户可能会发现32位系统上的ffvp9比预期慢很多；这是因为大多数SIMD优化仅适用于64位机器。如果你有32位软件，请将其移植到64位版本上运行。无法进行移植的话，则可能需要放弃使用旧版硬件了——因为如今几乎没有人还在用纯32位的x86设备。
最后，关于VP9解码性能与其他编码格式如何比较的问题：基本有两种方式测量这一点：相同比特率（例如500kbps VP8文件与500kbps VP9文件进行对比）或同质量下不同比特率。我们进行了同质量测试，并发现：
- ffvp9通常比ffh264稍快一点，但在Atom平台上则略有劣势。
- 与VP8相比，FFvp9速度较慢一些（约15%），尽管在“Enter the Void”这个特别案例中由于比特率的巨大差异而有所优势。考虑到Google承诺过VP9的复杂度不会比VP8高出40%，看来他们确实履行了诺言。
另外，在相同比特率的情况下，x264和ffvp9的表现基本一致（但x264在SSIM评分上略低）。与之相比，VP8则快约50%左右，但是视觉效果较差。
综上所述，尽管libvpx-vp9提供了一些多线程支持功能，在实际应用场景中FFmpeg的ffvp9解码器通常会表现得更出色，并且在处理复杂视频内容时能够更好地利用现代处理器架构中的SIMD指令集优化性能。这使得它更适合于高性能计算环境或需要实时流媒体传输的应用场景，尤其是在4K分辨率下的高质量视频播放方面具备明显优势。不过，对于特定平台（如Intel Atom）的优化工作仍有待进一步改进以实现更广泛的兼容性和更好的用户体验。总体而言，在追求最佳解码效率和图像质量时，FFmpeg中的ffvp9模块提供了令人满意的解决方案，并且在持续开发中有望带来更多性能提升的机会。
5星
