Because anyone that isn't just writing some kind of Quicktime front-end doesn't care about most of QTKit and the portion that does give you hardware accelerated decoding (which hasn't been around since 2005, no matter what matticus says).
Yes, it has. The Quicktime APIs for hardware acceleration were part of the "Core" technologies released with 10.4. CoreVideo and Quartz acceleration was essential to that massive rewrite.
All software written for OS X eventually passes through Quartz and Quicktime, because they are integral to the rendering system on OS X, which you might understand if you were familiar with the architecture-level issues.
Just as all software goes through Media Foundation on Windows (and is passed down to legacy-mode systems as necessary), everything on OS X goes through Quicktime at some point.
Quicktime player and the system Quicktime APIs are very different animals, and you are talking about "high level Quicktime" functions with regard to the player frameworks, evidently ignorant of the fact that Quicktime is part of the graphics system on OS X at the lowest levels.
It's just too high level. Things like Plex and Flash need to access to the decoded frame data to do some post-processing.
This is where it gets really silly for you. Quicktime is not a high-level API. It's a peer of OpenGL and is part of CoreGraphics, the Mac equivalent of Media Foundation.
Thus most everything passes through Quicktime on its way through the rendering system. The difference is how and where it chooses to communicate, which defines the level of hardware access (just as on Windows).
Plex and Flash do not
need to use stream decoders other than the system-provided ones (and indeed Plex is being rewritten to use
more of the system calls, not fewer--I was under the mistaken impression that this project had been completed, but it is still underway). They choose not to use the system APIs directly (for valid reasons), but to pretend it is impossible is a total fabrication.
Can the QTMovie class (and QTKit in general) deal directly with compressed video data in its raw, uncontainerized form? Or does it depend upon that data being passed into it encapsulated within a .mov/.mp4 container file?
The former is true. QTKit will load any video format playable in Quicktime, which included
direct FLV support until 2007 (and I believe again in Quicktime X).
If the former is true, then I suppose Adobe may have no excuse for not obtaining its video data in whatever container seemed most appropriate, and passing it into QTKit for decompression/rendering.
They do have an excuse, and that is because using QTKit would still require that they use their own decoder or ship an appropriate plugin pack for the more exotic types of Flash video, and they'd have to modify their overlay code. Neither are tremendous roadblocks, but they're valid decisions not to adopt.
It's also very new. It deprecates the older Quicktime API. HW Accel for video decoding was added late in the game and Adobe didn't even have time to implement it even if they could've used such a high level API in the first place. Matticus is just wrong here, he's just too proud to admit it.
You keep saying this, but you're absolutely wrong. It's not new at all; it's been part of OS X since the introduction of the Core technologies in Tiger. You need look no further than your own link:
http://developer.apple.com/mac/libr...tual/CoreVideo/CVProg_Intro/CVProg_Intro.html
Introduced in 10.4. The fact that you can't seem to separate hardware acceleration for video functions from the H.264 specialized acceleration speaks for itself.
Apple is responsible for lack of hardware decoding this round. They dragged their feet compared to Microsoft. Adobe did ship a beta with the feature though, barely a month or so after Apple gave them the API. That's far from what I call "lazy".
This is exactly what I'm talking about. This pretense that the H.264 codec has anything to do with anything must stop.
Nobody was calling Adobe lazy for not using the H.264 API--
it is new in version 10.1 for Windows, too. It didn't exist at all, anywhere, before this version, released this year.
The issue stems from their failure to update Flash player in the preceding years, allowing Mac performance to stagnate relative to Windows, and the fact that Adobe declined to update the codebase for Flash until version 10.1, which allows them to see significant performance increases because they now have access to OS X system APIs.