最近，Adobe 在 Flash Player 10.1 的 [release notes](http://labs.adobe.com/technologies/flashplayer10/releasenotes.pdf) 中这样写到：
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](http://en.wikipedia.org/wiki/VDPAU) API 用于视频硬件解码 — ffmpeg 和 [mplayer](http://www.mplayerhq.hu/design7/news.html#accelerationtips) 都对它有很好的支持。Mac OS X 呢？让我们罗列一下事实：
* 这里说的解码 — 主要是指视频，尤其是 [H.264](http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC) 视频的解码，因为音频解码功能需要的资源较少，最耗资源的就是 H.264 解码。
* 对于有 [nVIDIA 9400M](http://www.nvidia.com/object/product_geforce_9400m_g_us.html) 显卡的机器，Snow Leopard 的 [QuickTime X](http://www.apple.com/macosx/what-is-macosx/quicktime.html) 支持使用*未公开*的接口来硬件解码特定 profile (low, standard) 的 H.264 视频，这个兼容性虽然没有人详细测试过，但可以认为是比较有限的。QuickTime X 最大的限制是限死了对封装 (container) 格式的支持，在它支持的封装格式中，能使用 H.264 视频编码也就是 mp4 和 mov 两种，而在电脑上观看的高清视频大部分是 [mkv](http://en.wikipedia.org/wiki/Matroska) 封装的。
* 传统的 QuickTime 7 (在 Snow Leopard 中仍然可用) 虽然可以通过 [Perian](http://perian.org) 支持更多的格式，没有见到具体的报告讨论 QuickTime 7 能否使用 Apple 的 H.264 硬解码模块 ([AppleVAH264HW.component](http://arstechnica.com/apple/news/2008/10/digging-into-new-macbooks-support-of-gpu-accelerated-h-264.ars))，[Perian 社区](http://groups.google.com/group/perian-discuss)的讨论也没提到能否利用这个模块来解码 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](http://coreavc.com/) 开发者的 CorePlayer Pro，这是一个封闭的播放器，在 Mac 上不提供单独的解码器；至于 GPGPU 方案，市场上现有的只有 CoreAVC 基于 CUDA 的解码技术，他们确实有计划开发基于 OpenCL 的解码，但看起来仍然是一个很漫长的周期，而其他开发者因为缺乏足够的经验，很难涉足这个领域 — 没错，视频编解码的水很深。
以上这些事实造成的恶果是，Mac 用户空守着性能充足的显卡，在 OS X 上播放起 1080p 视频时往往 CPU 占用率在 100% 以上，播放高码率的 720p 视频也能到 70% ~ 80%。如果用了硬件解码，CPU 占用率会在 5% 以下，而基于 CUDA 的方案占用率也只有 10% 左右。
那我们能做什么呢？不管出于减少能耗还是减少机器发热的角度，都很有必要向 Apple [提交 bug 报告](http://bugreport.apple.com)，要求提供公开的 H.264 硬解码 API。
Apple也挺难的，高端机器（iMac/Mac Pro）上用的ATi显卡的视频加速在*nix上几乎不可用。单独支持VDPAU，很可能未来就绑定在nvidia上了
感觉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根本不在乎。
quote:”现在玩h.264的还是少部分爱好者了，Apple根本不在乎。”
—Apple就是靠这些设计师们最为核心的用户起家的了，而且这些用户才给Apple冠以神话的高帽和无尽的口碑；如果这都不在乎，Apple还在乎什么？
推广html5才是正道。
至于 GPGPU 方案，市场上现有的只有 CoreAVC 基于 CUDA 的解码技术
<– 这一句话有一点问题，CoreAVC的解码实际上还是用的DXVA，CUDA只用于从显存中Dump出DXVA解码后的数据，所以并不是真正意义上的GPGPU方案。除非CoreCodec重新开发，否则移植到OpenCL是不可能的。
“推广html5才是正道。”HTML 5是标准草案，内部编码还没吵干净，而且这个跟文中提到的视频解码支持不矛盾。难道大家就只能用Safari了以后？如果是的话，Safari推出一个随便什么标准就好了，何苦大家还要搞HTML？
@ssnake: 你确定？据我所知用 CoreAVC 选 CUDA 解码的时候是不需要 DXVA 的。
@jjgod：确定的，我专门查证过。CoreAVC网站的FAQ里也侧面提及了（现在是iPhone不方便找）。你可以再试试看。
@珠宝狼: 目前Safari, Firefox等浏览器都支持 tag吧。
硬解压有鸟用. apple 的低端 pc/laptop 都是 c2d, 解 1080p 戳戳有余. 随着硬件进步, cpu 的占用率进一步降低,能耗和热量问题都会成为历史