Chris Kenny
Well-known member
Thanks, useful info.
So could this also be interpreted as a major move away from QuickTime ?
and if so what implications may this have both good or bad ?
It is a major move away from QuickTime, yes. Which, frankly, has been in the cards since OS X shipped. It was inevitable that sooner or later there would be a modern Cocoa API capable enough to replace QuickTime.
Good implications are better performance, support for working with non-QT encapsulated media, color management, easier integration with 64-bit apps, and richer capabilities for developers to use. Potential bad implications are loss of compatibility with some old codecs, because I can't imagine Apple will bother to implement every old codec QT supports in AV Foundation. But at least for the foreseeable future QT will still remain in the OS alongside AV Foundation, so this isn't really a huge program. One other short-term bad implication is that I'm pretty sure the lack of video output in FCP X is related to capture/output device support not being fully implemented yet in AV Foundation, but it's inconceivable this isn't being worked on.
The attitude of the FCPX developers on this specific item is indicative of their attitude about the whole product. They know more than the people who actually use it, and those of us in the professional end of an industry should bow to their superior knowledge and realize that they're smarter than us, and that they know all about what we need and use.
Except that they don't.
There appear to be a series of fairly complex tradeoffs here; conflicts between backwards compatibility and new features/approaches, the potential benefits of trying to deliberately push the industry to change, etc. Users always want complete backwards compatibility, but if you always give it to them, your software will suffer in the long run both as a consequence of the resources devoted to providing that compatibility and the limits that compatibility imposes with respect to the kind of changes you can make.
Apple is much less conservative about backwards compatibility than most companies. I'm a little confused that this is a surprise to anyone, because it has been true for a long time and there have been many high-profile examples of it over the years. In my opinion, FCP moving to a new XML format or (the direction I think they'll go in) an API rather than a standard interchangeable static format, will be a lot like Apple axing 64-bit Carbon. When that happened, I got into a bunch of debates with people who said Apple was permanently crippling the Mac platform because Adobe would never port Creative Suite to Cocoa, and might even decide to just abandon the platform altogether. Adobe, of course, has now ported Creative Suite to Cocoa. Half of the reason Apple canceled 64-bit Carbon in the first place (which was working pretty well in Leopard developer previews) was probably to make Adobe do precisely this.
If Apple thinks they've got something better than the current XML format, and they support that exclusively in FCP X, I suspect it will have a similar outcome. Regardless of the current antipathy in certain circles, FCP X is going to sell a lot of copies and there's going to be demand for tools that interoperate with it.
Note (before the accusations start flying) that I'm saying all of this as someone who will be directly impacted if FCP X doesn't implement compatible XML exporting; I am not telling other people not to worry about an issue that doesn't affect me or that I don't understand the significance of.