Hint(s) to to a March Tiger?
There has been some speculation as to NAB being the launch pad of Final Cut Pro 5 especially with 2005 being called, "The Year of HD," by Steve Jobs and the release of Final Cut Pro HD (4.5) last year. FCP 5 will almost certainly require QuickTime 7 due to QuickTime 6's numerous shortcomings, not limited to the lack of 5.1 channel audio. Also, many expected 5 to be released at NAB '04 instead of a minor point release, this further suggests that Apple has probably been integrating QT 7 with this upcoming version.
If true, this would put Tiger on the road to a March release.
Anyone thinks this idea holds water?
If true, this would put Tiger on the road to a March release.
Anyone thinks this idea holds water?
Comments
Nice sig, by the way.
QT7 will surely be available for 10.2, 10.3... is 10.1 and previous supported by QT 6.5?
Originally posted by ZO
it is quite posible that QT7 will be ready for NAB
QT7 will surely be available for 10.2, 10.3... is 10.1 and previous supported by QT 6.5?
Found here:
Select Operating System:
? Mac OS X v10.2.8-10.3.x
? Mac OS 8.6/9
? Win 98/Me/2000/XP
So it seems 10.0 and 10.1 aren't supported.
so will be avaible only for tiger, and i think tiger will be avaible in june at wwdc
all in my opinion of course
Many pro apps have historically contained large bits of code deep in the guts that only later become generalized frameworks. Large parts of CoreVideo are actually from Motion, for instance. There is a tremendous engineering effort, however, in moving a library from being used in one particular specialized application to being a general purpose utility for any developer to use across the board. This is why you'll see functionality pop up in some apps, and only months or years later show up as system wide technologies.
Which was all a long way of saying that FCP-HD, while using CoreVideo, et al, and QT7, may (and I expect it to) actually ship ahead of Tiger, and even QT7. The necessary bits will be buried inside the app, and only those pieces required will be tested and kept private. Later, when the larger frameworks are ready for mass consumption, they'll ship with 10.4 and QT7.
I *still* know many video/audio/dtp pros who will RESISTS and NOT migrate to OSX until their OS9 box whithers and DIES... and then, they may even STILL try and find a 2nd (or 3rd) hand OS9 box.
If video pros are comfy with 10.2.8 and have no desire whatsoever to upgrade, I doubt Apple will be doing them a favor by saying "hey dude, you gotta buy 10.4 and probably change your settings, upgrade your other apps, and etc etc...)
OS9 to OSX is/was traumatic enough for many pros, I dont think Apple is going to tempt fate too much again
but the integration of qt 7 in the cocoa framework is a fact
of corse apple make tecnologies appare in application an then make it sistem-avaible, bat is a one way implementation. so they try pushing people to buy new ardware or at least software: tiger will be a must buy wen application will use core image/video. the differece will be simply too much, like use dos or mac in 1984.
Of course it will be optimized for Tiger, but they will have it everywhere because they want h.264 everywhere not to mention quirk fixes that should have been fixed in 6 like full screen controls and hopefully (prays to God) fullscreen playback as a NON-Pro feature.
Originally posted by gelosilente
probably apple will introduce plug in for qt 6 for support new codec.
but the integration of qt 7 in the cocoa framework is a fact
I think you have it backwards... there will be a Cocoa API for access to the QT internals, but it will be a layer *on top of* QuickTime 7. QT 7 could still be (and as a_greer pointed out will almost certainly be) ported to various other OSs to keep the momentum going.
Also, there's really nothing in Core* that precludes it being moved to 10.3, 10.2, or even Windows (except there the hardware permutations would be hell). If the hardware supports the functionality, then a simple library will provide the power.
The trick is, again, in making it something that other developers can use directly. It may be that Core* will be on Windows as part of QT7, but ONLY as part of QT7, not something that developers can directly access and use in their own apps, like it will be on Tiger. Similarly, it could easily be ported back to 10.3 or 10.2, but ONLY as part of QT7. If you want to write your own app that uses it directly, you have to move to 10.4, and so do your users.
And no, it's not just a product cycle driver for forcing people to upgrade - validating and supporting complex code like the Core* libraries is a *PAIN*. Developing them for internal use inside QT is one thing, ensuring that they are trouble-free and clean for external use is something else entirely, and every platform (including major version differences on OS X) that you add to the mix increases the workload for that validation and support supra-linearly, and darned near exponentially.
qt 7 for os 9 will never be.
qt 6 was the old qt4 with some new codec that require a new license fee for qt pro. qt 7 is not only cocoa, but is built on core video. maybe h264 will be used in a new qt 6 version, but qt 7 will only on tiger.
that is my opinion, in a few months will see
Originally posted by gelosilente
qt 7 is not only cocoa,
Ah, there's the problem.
QT7 is not Cocoa. There is a Cocoa API for it, but QT7 is not Cocoa at the core. Think layers.
Cocoa QTKit | Traditional Carbon API
------------------------------
QuickTime Engine
------------------------------
CoreVideo | CoreAudio | CoreImage
---------|----------|---------
CVEngine | CAEngine | CIEngine
That's how it would look on 10.4, because Core* are exposed for developers to use directly.
Under 10.3, 10.2, Windows, etc, it would look like:
Traditional Carbon API
------------------------------
QuickTime Engine
------------------------------
CVEngine | CAEngine | CIEngine
Notice that it's the same engines (the same code), it's just what's *exposed* that differs.
QuickTime7 will still have full Carbon access, the Cocoa API will be *additional*. A *new* way of accessing QuickTime, not a replacement.
And CoreVideo is already on 10.3, as part of the Motion application. It's just not accessible by anyone else.
Originally posted by Kickaha
And CoreVideo is already on 10.3, as part of the Motion application. It's just not accessible by anyone else.
indeed, and no other aplication will have that on 10.3
Originally posted by gelosilente
indeed, and no other aplication will have that on 10.3
You're missing the point.
CoreVideo *runs* on 10.3, it's just not *available to others* on 10.3. So they could easily, and obviously, have QuickTime 7 incorporate the same library Motion does, and have QT7 on 10.3 without shipping CoreVideo for 10.3 as a developer usable API.
Which means porting the underlying functionality of Core* to those systems.
Which they've already done for 10.2 and 10.3.
I don't know how I can make this any more clear.
os 9 users are not apple user