Rss

Is QTJ OK (for today)?

Great question from Ross on the last post:

Is QTJ not dead? I bought your book today out of interest, but it appears QTJ is a long time without updates and looking a little abandoned.
Would you still use it on a new project?

OK, first, thanks for buying the book. I hope you enjoy it.

Would I use QTJ today… it really depends. If a client asked me, my first two questions would be “what kind of app do you want to use it for”, and “how long does this app need to be viable?”

I’d need to know that so I could assess the project against what the facts currently are with QuickTime for Java. First, Apple stopped adding features to QTJ a few years ago. QuickTime 7 was the first time that the QT API picked up significant new functionality, without any attempt or plan to expose that functionality to QTJ. Among QT 7’s most important adds are support for frame-reordering codecs, metadata, and an audio API that basically makes it easier to to Core Audio stuff from a higher level in the call stack. The frame-reordering stuff was a profound change, necessary to support H.264, which replaces many sample-related functions: AddMediaSample became AddMediaSample2, and MediaTimeToSampleNum became either MediaDecodeTimeToSampleNum or MediaDisplayTimeToSampleNum (depending on what you were doing, since frame-reordering codecs require you to stop assuming that frames are decoded in the order they’ll be displayed and vice versa). Without this stuff exposed to QTJ, the practical upshot is that lower-level stuff doesn’t work if you try to use H.264, as I found with a capture app with an all-Java onscreen preview (more on that later, BTW), which choked on the frame decompress if you tried to compress the capture data to H.264 on the fly.

So, for some things, QTJ is already unacceptable. But what’s the future, and what are the alternatives? The future is that QTJ will go away. For one thing, they’ve obviously stopped putting new features into it. At an Atlanta Leopard Tech Day in 2006, some Apple reps asked me to not encourage people to start into QTJ projects, as the technology was not on their road map going forward. They will fix bugs and handle ADC support incidents, but it’s not getting any new work.

Of course, even if QTJ weren’t specifically on the “stay away” list, it’s based on some technologies that are already deprecated (notably QuickDraw), and the whole thing sits atop the main QuickTime API. Since we know that QuickTime, like all Carbon APIs, won’t be upgraded to 64-bit , it will eventually be deprecated as well (John Siracusa’s Leopard Review makes ths point better than I can). So even if Apple were maintaining QTJ, it’s a dead-end, because its underpinnings are destined for obsolescence.

But when? Apple is serious about getting rid of old stuff, and they usually follow three steps:

  1. Informally tell developers to stop using a technology
  2. Formally deprecate it
  3. Remove it from the OS

Right now, Apple is telling developers to stop using Carbon. It’s still available in Leopard, but its days are numbered. So maybe it will be deprecated in 10.6 and actually be absent in 10.7, but that’s pretty aggressive and possibly a worst-case scenario (and assumes that Apple can get Adobe and Microsoft, with their large Carbon code-bases, to go along). With two years between Mac OS X releases, that sets a minimum four-year viability on apps that require Carbon, including anything that uses the old QuickTime, including QTJ.

But what’s the alternative? The Apple guys said that in general, they were advocating QTKit. I thought at the time that that was because it’s object-oriented and thus more friendly to QTJ converts. But now we know that QTKit is the only 64-bit option, and long term, is presumably the future of QuickTime.

Well, the future of QuickTime on the Mac. Because after all, it’s single-platform.

So this gets me back to answering the question of would I recommend QuickTime for Java today. Despite Apple’s warnings, there are a few cases where I would. I haven’t fully broken this down yet — maybe it could be flow-charted — but here are the various factors I think go into a consideration:

  • Do you need to run on Mac and Windows? Go ahead and use QTJ, it’s more practical than writing straight-C QuickTime for both platforms, and the alternative would be to use QTKit on the Mac and the little-understood QuickTime COM on Windows. You still might be screwed long-term, but if Carbon QuickTime is going away, that leaves a big open question of what Apple will do with QuickTime for Windows (they didn’t reply when I asked last year)
  • Do you need to do editing or access low-level functions? QTKit remains an 80/20 proposition, so if you’re in the 80% that just wants to play media or maybe support cut/copy/paste editing, you’re good. If you want to support things like effects, tweens, or write samples to a new movie, I’d have to do some prototyping before I was comfortable recommending it… those kinds of hardcore features are the 20% that may not be in there. In cases like this, QTJ or old QuickTime may be a better choice
  • How long does this code have to be viable? For green-fields development that you hope is going to be in use for years, QTJ and QuickTime are probably a bad choice, given that we’ve been explicitly told to move off of them. For short term stuff, including demos, experiments, and prototypes, they both work today and should be viable for a while yet. I also think hobbyists can go ahead and use QTJ because it’s probably a more practical way to introduce yourself to QuickTime’s concepts than using the straight-C API, and there’s no definitive book on QTKit yet (and even QTKit often assumes you get some of QuickTime’s deeper concepts, which doesn’t help the beginner).

So, does that answer your question? I’m figuring not, because I’ve just burned about a thousand words to say it depends

Comments (5)

  1. Ross

    Yes, great post, and it does actually answer my question – thank you for spending the time to elucidate.

    I need QT support on both Windows and OSX, although common sense tells me that Windows should be the priority (for financial reasons) I have a deep-seated urge to ensure that it also runs on OSX (and also a deep deep distrust and dislike of Directshow).

    I am going to spend a little more time with QTJ to check out the performance characteristics, but I fear that its limited lifespan will more than likely mean that QTJ would be a short-term solution to a longer-term project/product.

    I guess I could hold out for QTPython đŸ˜‰

  2. […] Maybe QTJ is less OK than I thought. […]

  3. felix_chung

    Thank you for the post. The nugget about 64-bit unlocked our problem. We are deploying on Tomcat 5.5 with an early 2008 Xserve w/8GB RAM. We changed the JVM flag to use 64-bit addressing to allow us to slurp on that RAM – but little did we know that QTJ doesn’t like it. Went back to 32-bit (lame) and all is fine.

    Any ideas on getting QTJ to run on 64-bit? We would really like to use that RAM…

  4. felix_chung: No, I don’t think there’s much hope of getting QTJ happy on 64-bit, considering the point of this piece is that Apple really has walked away from QTJ and, moreover, the QuickTime underpinnings of QTJ are also stuck on 32-bit. I guess the question is, what are you doing with QTJ on your server? If there are equivalent method calls in QTKit, which is the 64-bit future of QuickTime, then you might want to look to making a Java-to-native call to those via JNI, JNA, or perhaps the just-getting-started Rococoa. I guess for the truly heroic, there might be some prospect of isolating your QuickTime/QTJ work in a separate process that you could kick off in a 32-bit space while leaving your server running 64-bit, but then it really becomes a question of what you’re doing with QuickTime and whether that’s really a practical option.

  5. […] Tech Day Atlanta in 2006, as I was considering calling it from Java with JNI, and (as previously noted), I got no reply at all. And every other public question I’ve seen about the future of […]

Leave a Reply

Your email address will not be published. Required fields are marked *