I've measured the CPU usage of playing an H.264 clip at 18% for QuickTime Player, and 90% for Flash 10.1 beta. This was on a machine that does not have any hardware to accelerate H.264, and the number for Flash was measured while there was no interaction with the Flash object, and nothing was being overlaid above the video itself. If we assume that Flash's software decoder actually is at least as efficient as the one built in to the OS, then that means that the non-decoding work (color space conversions, compositing, scaling, and any overhead due to the plugin API) adds up to at least four times more work than the decoding itself. This is while the compositing and scaling are trivial! (The video was being played at native size, not fullscreen, and with nothing overlaid.)

If the plugin system really causes that much trouble, then why was Adobe complaining about the lack of a low-level API for hardware-accelerated H.264 decoding? It would seem that they are in more dire need of a much-improved plugin architecture, so that they can outsource more of the compositing and color space conversion.

Since Adobe has tried to excuse a lot of the performance problems as due to the lack of an appropriate H.264 API, it's time for them to put their money where their mouth is. If they release a new plugin that uses this new API, and the performance is hardly improved, then it means the complaints about the lack of this API were merely a red herring to shift as much blame as possible to Apple and to distract from the real causes. If performance does increase significantly, it will mean that Flash's software decoder was shit all along, and we can move on to bashing Apple for only supporting 3 of the many hardware H.264 decoders that they ship.

The blog you link to makes it clear that there need to be major changes to how in-browser video is handled. It also makes it clear that Adobe's stance is that it is the duty of the operating system to provide APIs that fit Flash's rendering pipeline, rather than have Adobe redesign the Flash player so that it can take advantage of existing acceleration APIs. In the case of the Linux plugin, there are several different APIs that are potentially useful, but Adobe is waiting for the dust to settle and for a clear winner to emerge. Given what we've seen on OS X about how the exact nature of the APIs matters so much to Adobe, it is odd that they are avoiding participating in the open-source process by supporting a particular API and helping ensure that it will meet their needs.