Mac OS X 视频解码技术之现状

最近,Adobe 在 Flash Player 10.1 的 release notes 中这样写到:

In Flash Player 10.1, H.264 hardware acceleration is not supported under Linux and Mac OS. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs. We will continue to evaluate adding the feature to Linux and Mac OS in future releases.

然而实际上 Linux 下已经有了比较完善的 VDPAU API 用于视频硬件解码 — ffmpeg 和 mplayer 都对它有很好的支持。Mac OS X 呢?让我们罗列一下事实:

  • 这里说的解码 — 主要是指视频,尤其是 H.264 视频的解码,因为音频解码功能需要的资源较少,最耗资源的就是 H.264 解码。
  • 对于有 nVIDIA 9400M 显卡的机器,Snow Leopard 的 QuickTime X 支持使用未公开的接口来硬件解码特定 profile (low, standard) 的 H.264 视频,这个兼容性虽然没有人详细测试过,但可以认为是比较有限的。QuickTime X 最大的限制是限死了对封装 (container) 格式的支持,在它支持的封装格式中,能使用 H.264 视频编码也就是 mp4 和 mov 两种,而在电脑上观看的高清视频大部分是 mkv 封装的。
  • 传统的 QuickTime 7 (在 Snow Leopard 中仍然可用) 虽然可以通过 Perian 支持更多的格式,没有见到具体的报告讨论 QuickTime 7 能否使用 Apple 的 H.264 硬解码模块 (AppleVAH264HW.component),Perian 社区的讨论也没提到能否利用这个模块来解码 H.264,同时用 ffmpeg 来解析 mkv 封装格式。
  • 因为 Mac OS X 下所有显卡的驱动都是通过 Apple 分发的 — 显卡厂商自己没有发布过这些驱动,也没有权力提供用户空间的库来调用自己显卡中的硬件解码 API (实际上这显然还是得内核支持的),如果 Apple 不公开视频硬解码 API,造成的结果就是没有一个第三方的应用程序能利用 Mac 上完全充足的硬件 (9400M, 9600M 等等) 来解码 H.264 视频。
  • 除了硬件解码之外的方案还有纯软件解码和基于 GPGPU 的方案,前者,Mac OS X 下可用的是 ffmpeg 的 H.264 解码功能,mplayer, Perian, Movist 等播放器用的都是它,还有一种是 CoreAVC 开发者的 CorePlayer Pro,这是一个封闭的播放器,在 Mac 上不提供单独的解码器;至于 GPGPU 方案,市场上现有的只有 CoreAVC 基于 CUDA 的解码技术,他们确实有计划开发基于 OpenCL 的解码,但看起来仍然是一个很漫长的周期,而其他开发者因为缺乏足够的经验,很难涉足这个领域 — 没错,视频编解码的水很深。

以上这些事实造成的恶果是,Mac 用户空守着性能充足的显卡,在 OS X 上播放起 1080p 视频时往往 CPU 占用率在 100% 以上,播放高码率的 720p 视频也能到 70% ~ 80%。如果用了硬件解码,CPU 占用率会在 5% 以下,而基于 CUDA 的方案占用率也只有 10% 左右。

那我们能做什么呢?不管出于减少能耗还是减少机器发热的角度,都很有必要向 Apple 提交 bug 报告,要求提供公开的 H.264 硬解码 API。

Author: jjgod

A software engineer from China, working on text rendering for a fruit company. Interested in typography and science fiction.

14 thoughts on “Mac OS X 视频解码技术之现状”

  1. Apple也挺难的,高端机器(iMac/Mac Pro)上用的ATi显卡的视频加速在*nix上几乎不可用。单独支持VDPAU,很可能未来就绑定在nvidia上了

  2. 感觉Apple很没动力去做这件事啊,几个因素吧:

    • QT X现在支持mp4封装的h.264硬解码。这个基本解决了iTunes Store里面购买的正版720p视频的播放问题。而现实中大部分mkv封装的视频基本上是BT来的盗版。考虑到Apple对mp4容器的支持,它估计不怎么愿意去支持mkv。那自然的,开放API给ffmpeg就没那么要紧了。

    • ATi/NVidia两家的API不通用,Apple也不想吊死在任何一家上。如果Apple当年从PowerPC转到x86这个过程中学到什么的话,估计就是它巴不得所有的commodity components能够互换,省得自己出钱出力去维护API。现在的ATi/NVidia两家情形有点类似,因此就算Apple打算侧重一家,应该都还在观望看到底谁比较有戏。太早选定型以后再改的成本太大了。

    • [个人猜测]Apple可能不觉得独立的GPU或者GPGPU能撑多久,5年后的趋势也许是混合芯(也许来自AMD,也许来自Intel)。现在虽然GPU算浮点是快很多,但是毕竟是另外一套编程思路了,少部分做视频或者高性能计算的能用上,普通开发者估计不太愿意去学习另外一套API。OpenCL虽然性能上差点,但是好处是通用啊,普及起来容易很多。Apple也不用担心现在到底是用ATi呢还是NVidia、以后到底是dedicated GPU还是hybrid C/GPU这样的头痛问题。

    • 还有iPhone用的既不是ATi也不是NVidia,但是也需要h.264硬解码,要是开放API,这里又得是另外一套东西了。Apple怕维护难吧。

    • 其实最核心的是h.264现在还是没那么普及。欧美好多人还在看DVD。Blu-Ray才刚开头,Apple产品上现在连个Blu-Ray的光驱都没有(很怀疑2年内会不会有),也不存在说用户买回家发现播不了的问题。现在玩h.264的还是少部分爱好者了,Apple根本不在乎。

  3. quote:”现在玩h.264的还是少部分爱好者了,Apple根本不在乎。”

    —Apple就是靠这些设计师们最为核心的用户起家的了,而且这些用户才给Apple冠以神话的高帽和无尽的口碑;如果这都不在乎,Apple还在乎什么?

  4. 至于 GPGPU 方案,市场上现有的只有 CoreAVC 基于 CUDA 的解码技术 <– 这一句话有一点问题,CoreAVC的解码实际上还是用的DXVA,CUDA只用于从显存中Dump出DXVA解码后的数据,所以并不是真正意义上的GPGPU方案。除非CoreCodec重新开发,否则移植到OpenCL是不可能的。

  5. “推广html5才是正道。”HTML 5是标准草案,内部编码还没吵干净,而且这个跟文中提到的视频解码支持不矛盾。难道大家就只能用Safari了以后?如果是的话,Safari推出一个随便什么标准就好了,何苦大家还要搞HTML?

  6. @jjgod:确定的,我专门查证过。CoreAVC网站的FAQ里也侧面提及了(现在是iPhone不方便找)。你可以再试试看。

  7. 硬解压有鸟用. apple 的低端 pc/laptop 都是 c2d, 解 1080p 戳戳有余. 随着硬件进步, cpu 的占用率进一步降低,能耗和热量问题都会成为历史

Leave a Reply

Your email address will not be published. Required fields are marked *