What features do you think Quicktime 7 will have?
Panther has a new version of Quicktime coming. Just a slight revision but the ability to playback Multichannel Audio and other small architectural improvements are always welcome.
Next year it looks like QT7 may be announced at the next Quicktime conference from Apple. I think QT7 will probably be a fairly major revamp. I have no idea what it will contain but I wouldn't be suprised to see it undergo some pretty big changes.
I was wondering is QT7 would go more to a component type architecture. Somewhat of a Mothership/Satellite approach in which QT would be the main central hub but would now extract it's Audio and Web features in lieu of Core Audio handling Audio/Midi, Webcore/Webkit handling HTML.
Perhaps in a in a structure like this it will be easier to make core changes to certain parts of Quicktime without adversely affecting the other parts.
Does anyone one else have any thoughts about this or what they would like to see in Quicktime 7?
Next year it looks like QT7 may be announced at the next Quicktime conference from Apple. I think QT7 will probably be a fairly major revamp. I have no idea what it will contain but I wouldn't be suprised to see it undergo some pretty big changes.
I was wondering is QT7 would go more to a component type architecture. Somewhat of a Mothership/Satellite approach in which QT would be the main central hub but would now extract it's Audio and Web features in lieu of Core Audio handling Audio/Midi, Webcore/Webkit handling HTML.
Perhaps in a in a structure like this it will be easier to make core changes to certain parts of Quicktime without adversely affecting the other parts.
Does anyone one else have any thoughts about this or what they would like to see in Quicktime 7?
Comments
quicktime development seems to be somewhat...how do i say it.....fast? 6.3 came out relatively recently, 6.4 in a few months, 7.0 next year? sweet.
They should include the 3ivx plugin!
Originally posted by Ebby
Among the many positive points made here; we will see more nut-crushing copyright restrictions. However, I would like to see basic Windows Media/RealPlayer media support. That would be cool. 8)
I don't think the restrictions will be anything signifigant, just like the iTMS(except for the 3 Mac rule). Personally, I don't think we will see any restrictions at all.
They need to get rid of the QT Pro ad, though.
http://arstechnica.infopop.net/OpenT...1&m=9860908475
I like the OpenGL scaling suggestions. Quicktime is in definite need of a overhaul. The featureset right now looks pretty good. But they need more modern "guts" and much better documentation.
The current C API is just horrendous.
Cocoa and Java APIs would rock (in the keynote, they promised better support in Cocoa at least). At this point, they can't get rid of all that old cruft, but at least they can bury it under some proper classes.
I also noted that they talked about better reentrancy for the QT APIs at the keynote. Yay. It sounds like it's getting a real overhaul. There are a lot of areas where it can be sped up, too, and I'm hoping for that (especially on Windows! Gah!).
There's already a Java API, has been for a while. It does a pretty darned good job of giving access to the most useful bits of QT, but it falls down on the fine-tuning issues.
But yeah, it's the MacOS Toolbox crud that's been holding back a good an proper Cocoa API. A Java API over C isn't too bad, but a *well done* Obj-C API is, oddly enough. Java lacks the pervasive dynamicism that Obj-C has, so it's easier to mesh to the underlying memory/thread model. Creating a Cocoa API OTOH, requires integrating into the Cocoa thread model, etc, etc, etc... which looks nasty, as long as they retain the underlying legacy code.
Another issue with QT seems to be one of Marketing. You mention "Quicktime" to even Mac users and most know it as a Player and not an Architecture or Format.
Is QT in it's current form able to form the basis of small Multimedia devices? Linux seems to have made inroads into small set top boxes and other devices like that. Is QT not strong in these areas to compete? I find it strange that recent years have held so much promise for QT as in QTV and that announcement about many Digicams using QT but either it these did not reach fruition or I'm just not aware. I say add just a couple needed features. Then freeze things and rewrite QT to make it modern and scalable for the next Decade. Document the hell out of this and start pushing QT right.
Originally posted by Kickaha
Amorph:
There's already a Java API, has been for a while. It does a pretty darned good job of giving access to the most useful bits of QT, but it falls down on the fine-tuning issues.
Well, serves me right for talking about Java when I only keep half an eye on it.
Thanks for the correction.
But yeah, it's the MacOS Toolbox crud that's been holding back a good an proper Cocoa API. A Java API over C isn't too bad, but a *well done* Obj-C API is, oddly enough. Java lacks the pervasive dynamicism that Obj-C has, so it's easier to mesh to the underlying memory/thread model. Creating a Cocoa API OTOH, requires integrating into the Cocoa thread model, etc, etc, etc... which looks nasty, as long as they retain the underlying legacy code.
This is probably one big reason why they're talking about greatly improving the reentrancy of the QT APIs.
The implications for QT for Windows are pretty interesting, too. It might mean that they can get rid of the whole kludge of running QT on a port of the Toolbox(!) and write it more closely to the underlying Windows APIs. I can't imagine that would hurt.
The struggle will be to make sure that the content authored in QT 1.0 still runs. Considering that they highlighted that capability of QuickTime's in the keynote, they must be confident that they've found some way to do it.
Amorph:
Why would QT 1.0 *files* be affected? Or did you mean code written to the QT 1.0 API? A layer that hands off from the OO to procedural or back isn't out of the question.
Originally posted by Kickaha
Amorph:
Why would QT 1.0 *files* be affected? Or did you mean code written to the QT 1.0 API? A layer that hands off from the OO to procedural or back isn't out of the question.
I'm going from the thesis that playback and manipulation of QT 1.0 files would be affected, because that implies an application written to the QT 1.0 APIs. Generally, the file format codifies assumptions about the nature and organization of the libraries used to create and manipulate the content it stores, and vice versa. I'm imagining that some sort of compatibility layer would be required, and depending on exactly how much replumbing they're doing it could be a bear - for instance, if they'd have to make a new, asynchronous library act like an old, synchronous one. At least reentrancy is a simpler problem from a compatibility perspective.
Apple made a big deal about how "content created in QT 1.0 still runs in QT" so they seem to consider it a nontrivial accomplishment.