Rebooting Java Media, Act II: Development

by Chris Adamson


What does a modern Java media library needs to be? Part 2 of this series looks at the ideas and capabilities of the current crop, including Java Media Framework, QuickTime for Java, IBM's MPEG-4 Toolkit, and more. Part 1 set up the premise that the read/write nature of Web 2.0 requires media libraries to offer creative capabilities and not just playback, and argued that Desktop Java needs to offer more ambitious functionality to avoid being rendered irrelevant by webapps, Ajax, and Flash. Part 3 will discuss designs for an ideal Java media library and try to figure out who'll pay for it.


10 Comments

Frank Smith
2006-12-30 09:21:53
Hopefully you are more informed about media frameworks than about Indiana. You may have thought your insulting characterization was funny or clever, but I believe your article would have been much better without the offensive (and inaccurate, based on my experience) remarks.
haxie
2006-12-30 10:42:03
Great series Chris... I have struggled trying to work with QTJ for a long time due to my lack of understanding of the original C API. It seems that there is a lot of background info that you have to have in order to use QTJ to it's full potential and as you said it can be a "deep and dark" ride of mysterious calls and larger structure build ups (build ups? : ) in order to get things done.


Anyway, great article and I look forward to reading more.


BTW: I am from Montana and you can use it in your characterization if you want, we have thick skin and can take a good joke...


Chris Adamson
2006-12-30 10:52:36
Frank: my family moved to Fort Wayne, Indiana, for a couple of years when I was young. The school didn't know what to do with me and wanted to promote me three grades, my optometrist didn't know what to do with my lazy eye and wanted to put a patch on it (I was 8; it was surgically corrected when I was 10), and I caught viral encephalitis and slept through most of a summer. Moving back to Detroit was a genuine salvation (and I know that must sound funny to many people).
Chris Adamson
2006-12-30 10:54:52
haxie: my QTJ book is on Safari, and Safari has a free trial, so you could read it for free and see if that helps cut through the clutter of the admittedly-scary API.
Ian D
2007-01-02 16:03:46
Java developers on Windows can also use DSJ, a terrific library that wraps the native DirectShow, allowing Java programs to play pretty much anything supported on the host pc.
cooper
2007-01-03 07:40:10
I must say, I still have to part company with you on the idea that,
And here's a little irony to consider: Flash is taking over web video with H.263 knock-offs... and JMF offered all-Java H.263 playback in 1999! So, dot-com crash notwithstanding, why wasn't YouTube delivered as an applet seven years ago?! I'd submit to you that, once again, distribution problems are the deal-killer for client-side Java.


Distribution doesn't strike me as a problem. If everyone wanted Java, everyone would have it. The problem is one of code quality -- the Flash plugin works, and works properly even with things like the newer ExternalInterface in every browser, period. The Java Plugin has, it seems, about a 50% chance of crashing Firefox simply by loading up, a 40% chance of noiniting for mysterious reasons on Safari and MSIE and Opera aren't even worth talking about. Nevermind that LiveConnect barely works in the Netscape-derived browsers, let alone working the same way in all of them -- and it is also a problem of user experience -- making a Java Applet look nice and start up fast is nigh impossible for the non-expert. Anybody can make a Flash MP3 player in about 45 minutes of poking at it that looks good.


Again, I don't think the problem is so much one of codecs, I would be perfectly happy if Ogg/Vorbis would just get added to the JRE and that would be the "Java" version of media, but you still need, to go along with that, the niceties you get with Flash: autobuffering of playback streams over the internet and a playback API that you can learn in less than an hour.


Now, to contradict what I just said, however, Flash isn't about desktop applications. If people want to pimp Java as a desktop application language, codec support (not to mention non-s**t HTML support and ease of non-s**ty UI development) are pretty much critical to that in this hybrid online/offline world. Now, I always like to note that the Law and Order games are the only "Java" apps (actually Java+QTJ) you can buy over the counter at CompUSless or Best Buy. You go look at the kids games areas and fully half of them are some combination of Director and Flash destined for the desktop for just this reason. Moreover, I can't help but look at things like Banshee and Jokosher in the Linux world and wonder why we don't see Java apps of the same bent. There you need the whole stack (and in the case of Jokosher, more of your full-editing suite). IonDB is the only somewhat impressive Java media app on the desktop, and that is because of a nearly herculean effort on the part of the dev team to create platform specific versions for the WLM platforms.

Bharath R
2007-01-11 19:34:57
Chris,
How about drawing more (of Sun's) attention to JMF through the java.net editorial? While the community is painfully aware of JMF's inadequacies, Sun seems to be blissfully unaware (intentionally, perhaps). What we need is a real wake up call. (It's never too late to attempt defeating flash, IMHO).
Chris Adamson
2007-01-12 06:31:42
Bharath R: well, one reason I put this on ONJava was to not abuse my prominence as the java.net editor. I really see my public role there as more of an MC, presenting what the community is up to in terms of projects, blogs, forums, etc. It's not appropriate for me to put much of my own beliefs in there, because it might chill those who don't agree with me and don't have the big prominent daily blog. So, if everyone there wants to talk about new JDK 7 property syntax proposals and not multimedia or device support, then what I blog about there is what the community's talking about.
Chris Adamson
2007-01-12 06:40:07
Typo: I said Sorenson Spark is "another H.263 derivative", whereas the Wikipedia article I link to clearly indicates it is thought to be an H.264 derivative.
studdugie
2007-11-14 07:11:27
Great post. Keep beating the drum brother.