|
|
|
|
|
by jdowdell
5970 days ago
|
|
Plugins on Mac browsers still have no API to offloading video decompression to hardware... QuickTime excepted, that is. Kevin's stats were comparing CPU-decompression of video, which should get closer to parity. Apple's APIs would be easier to use, were they to provide guidance and resources more like Microsoft does. Stark difference. |
|
Adobe has stated that the APIs aren't sufficient, but I haven't seen any of you explain what exactly you do need. If you're looking for an API to specifically feed data to a dedicated decode chip, you're doing it wrong, because hardware abstraction is the operating system's job.
If it's merely a problem of the Quicktime APIs being hard to use, then you deserve a swift bankruptcy for complaining about it publicly rather than learning how to program properly on a Mac.
The simple fact remains that Flash is so resource-hungry that it is undeniably badly written. On my machine, with a Radeon X1600 GPU that doesn't have any useful h.264 acceleration, playing a certain h.264 video with a resolution of 640x360 causes Flash 10.1 beta 2 to use on average 90% CPU, whereas Quicktime Player playing from a file uses a steady 16%. Flash is wasting three quarters of my CPU cycles on overhead. Yes, I can understand a difference of a few points due to extra layers of IPC and the networking code, but even if I'm generous, the latest-and-greatest Flash pre-release is throwing away every other clock cycle that my CPU has.
Edit: I tested the video on VLC as well, to make extra sure that there is no home-field hardware acceleration advantage for QuickTime. VLC uses about 18% CPU. Flash's software decoder is 4-5 times slower than it should be.