I'd like some clarification on that point, because there appears to be conflicting information.I'll translate that to English: No non-MOV containers need apply, with the old API. All parties welcome, even Enemies of Steve, with the new API.
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?
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.
If the latter is true, then QTKit would have been out of the question for the majority of Flash video, carried by the .flv container which is incompatible with .mov/.mp4.
Adobe actually supports two different container formats right now - .flv and .f4v - one of which is proprietary and the other is based upon the MPEG-4 part 12 base container with proprietary extensions (that may or may not confuse QTKit -- I don't know). Either .flv or .f4v can be used to contain H.264 video, but only .flv can be used to contain their older legacy codecs.
Given the containerization used for .f4v files might be compatible with QuickTime (depending on whether QuickTime can handle, or at least graciously ignore, the proprietary extensions), and the fact that Adobe only allows a limited set of audio and video codecs within .f4v files, I suppose they might have separated out .f4v files from the .flv files right from the start and passed .f4v files directly to QTKit... Except, when the time came to execute the proprietary extensions embedded within the .f4v container such as ActionScript and still images, how would the Flash Player take care of synchronizing those actions with the QTKit's movie player?
They probably would unavoidably need to have their own code for decontainerizing any video provided in .flv files due to the proprietary nature of the container -- and then, depending upon the codec within the .flv, they might have been able to pass any video in a compatible codec on to QTKit as well, and only render the incompatible codecs themselves... Presuming QTKit allows decontainerized data to be supplied directly...