What features do you think Quicktime 7 will have?

hmurchisonhmurchison
Posted:
in Mac Software edited January 2014
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?

Comments

  • Reply 1 of 20
    cooopcooop Posts: 390member
    QTMS (QuickTime Movie Store)
  • Reply 2 of 20
    chef ramen noodlechef ramen noodle Posts: 42member
    definately!



    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.
  • Reply 3 of 20
    buonrottobuonrotto Posts: 6,368member
    A serious revamping and spring cleaning of the plumbing -- plug-in architecture, APIs, documentation, etc. to get into line with so much other tech in OS X. I think Apple should stop emphasizing it as a player and more as an architecture, sell it not only hardware peripheral makers (they've been fairly good at that), but also other software makers to incorporate it into their applications.
  • Reply 4 of 20
    aquaticaquatic Posts: 5,602member
    And release iApps for Windows that use it. Especially iTunes for the iPod and iTMS. And if they release other hardware then those respective apps, like iPhoto, or iMovie.



    They should include the 3ivx plugin!
  • Reply 5 of 20
    ebbyebby Posts: 3,110member
    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)
  • Reply 6 of 20
    cubedudecubedude Posts: 1,556member
    Quote:

    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.
  • Reply 7 of 20
    hmurchisonhmurchison Posts: 12,425member
    I posted this over at Ars. There are some good suggestions there as well.



    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.
  • Reply 8 of 20
    kickahakickaha Posts: 8,760member
    And please, dear God, a Cocoa API???



    The current C API is just horrendous.
  • Reply 9 of 20
    ghost_user_nameghost_user_name Posts: 22,667member
    Who remembers a few years back at a Keynote where Jobs talked about QuickTime TV. They had a domain and everything for it... talked it up to be something big and cool too. Who dropped the ball on that one?
  • Reply 10 of 20
    amorphamorph Posts: 7,112member
    There are a lot of issues with QT. Considering, it's solidly built and it's held up well, but the limitations of classic Mac OS are an albatross around its neck at this point.



    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!).
  • Reply 11 of 20
    buonrottobuonrotto Posts: 6,368member
    QTV was stillborn IMO. Nice idea, way too soon. They thought that everyone would flock to the web for entertainment, but of course no one did, and no one really has in that sense yet either.
  • Reply 12 of 20
    kickahakickaha Posts: 8,760member
    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.



    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.
  • Reply 13 of 20
    lucaluca Posts: 3,833member
    Hopefully it's fast. I haven't had any problems with QT6 in Jaguar, but it's horribly slow in the Panther preview on my iBook 800 MHz. And it's just as bad with my brother's 400 MHz G4. But I have a feeling Panther will get some major changes before the final version comes out. Right now it's not much more than Jaguar with fast user switching, exposé, and a new Finder.
  • Reply 14 of 20
    hmurchisonhmurchison Posts: 12,425member
    What are the potential dangers of a total rewrite of Quicktime. Since so many apps have deeply embedded QT code could this be a potential nightmare for compatability problems?



    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.
  • Reply 15 of 20
    amorphamorph Posts: 7,112member
    Quote:

    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.



    Quote:

    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.
  • Reply 16 of 20
    buonrottobuonrotto Posts: 6,368member
    Is it possible to take anything form the old NeXT movie player (whatsitcalled?) frameworks and put it to use in QT? Probably not, but I thought I'd throw it out there.
  • Reply 17 of 20
    kickahakickaha Posts: 8,760member
    NeXTTime (baaaaad name) was a reverse engineered framework for QT compatabililty. It's way old, way out of date, and probably not going to help much with all the new QT stuff that needs to be incorporated.



    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.
  • Reply 18 of 20
    ibrowseibrowse Posts: 1,749member
    If QuickTime Player 7 could handle Windows Media documents (better than WMP for Mac would not be a hard goal to shoot for at all...) I would be so happy. I try to stray from any files with the .asf or .wmv extensions just because I hate using WMP, but sometimes I have no choice. If the poor (by poor I mean horrible) Windows Media Player for OS X is revenge for QTPlayer for Windows being so bad, they went overboard.
  • Reply 19 of 20
    aquaticaquatic Posts: 5,602member
    If MPlayer can play them, why the hell shouldn't Apple add that open source into the QT 7 architecture.
  • Reply 20 of 20
    amorphamorph Posts: 7,112member
    Quote:

    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.
Sign In or Register to comment.