JMF: A Mistake Asking to Be Re-Made
by Chris Adamson
Oh no, not again.
JMF, the Java Media Framework, has had a history that can honestly be described as alternating periods of ineptitude and neglect. The fact that the JMF home page has only seen three updates in the last two years, and none in the last twelve months, indicates that JMF is in the latter state.
And now this post to the JMF-INTEREST list:
I'm T--- W---- and have recently taken responsibility for JMF at Sun
We are in the process of planning what to do with JMF and would like
hear from you
regarding how you are using JMF and what your needs are. Please feel
free to contact
me directly as some of the other feedback channels are currently not
Oh, where to begin?
OK, before I offer any more criticism, I need to acknowledge that I'm the author of a book on QuickTime for Java, a rival Java media framework. Some may think I'm trying to goose my own book sales. Think that if you like, but the book's been out for a year and has probably sold most of the copies that it's ever going to.
And let me add this: I started with JMF. If it were good, I might never have moved on to QTJ. After all, QTJ is limited by the fact that it only works on platforms with native implementations of QuickTime -- meaning only Mac and Windows. An all-Java media framework would be tremendously valuable to the Java platform.
But I am absolutely convinced that Sun is in no way capable of creating such a thing.
The proof of this is in the results: since its release in 1998, JMF has gained practically no traction, and has been largely ignored since the release of JMF 2.0 in late 1999. We've gone six years with virtually no substantive work on the framework.
A little history as to how we got here... With no experience, credibility, or patents in the media field, one might have expected Sun to take on a partner in developing JMF, someone like Macromedia (Flash), Apple (QuickTime), or Real. Instead, they developed JMF 1.0 with Intel, and 2.0 with IBM.
JMF 1.0 was quickly pulled together to enable playback of dynamic media -- audio and video -- in Java desktop applications. JMF 2.0 added capture, streaming, and pluggability. But because of the high demands of media and the modest performance of late 90's VM's (and the capabilities of the hardware they ran on), all-Java media handling realistically needed to be bolstered by native "performance packs", which improved JMF on supported platforms by using high-performance native code, and access to the platfrorm's native media frameworks.
So... what's the problem? Here are a few:
- JMF has no editing API, nor any meaningful concept of media in a stopped state. That means it can't be used for building, say, a podcast editor (can't trim your clips), or iTunes (no metadata API for reading the track titles). Aside: what's the point of a capture API if there's no way to edit the captured data (apparently, the capture is only useful for streaming applications).
- Sun made a performance pack for Solaris, that ubiquitous champion of the desktop, and not for Mac Classic or Mac OS X.
- The included codecs supported few media types in common use at the time, and those that were used in 1999 (Cinepak) have fallen out of use.
- The system for managing plug-ins, the "JMF Registry", was extremely brittle.
- The scheme for finding an appropriate plug-in used the wildly inefficient tactic of using exceptions for program flow.
- Sun expected Macromedia to develop the Java support for the Flash format, and Macromedia lost interest, leaving JMF supporting only Flash 2.
Now it's six years later and what's been done? MP3 support was taken out of JMF for a few years due to licensing concerns, then put back in. Other than that, the framework has languished. Sun got interested in JMF again in July 2002, but they couldn't actually hire anyone to work on it, and ended up not actually doing anything with it. So, developers come along, try to discover what it can do, and often wander off in disgust that it can't work with modern formats. Some go to QTJ; many more probably call native frameworks with JNI, or just abandon Java altogether.
Now Sun wants to know what to do with it? Seriously?
Look, nobody developing a commercial application could risk Sun walking away from JMF for another six years. And given the utter lack of interest from third parties in extending this built-to-be-extended platform -- it would be straightforward to bring Real to JMF via the open-source Helix platform, but nobody seems to have bothered -- there's no realistic chance of a third party coming to the rescue.
And seriously, what's the point? Does Sun have a strategic vision for JMF? Is there some genuine value it can bring to the Java platform? Will putting dollars into new development pay off someday? Are these questions really going to be answered by casually throwing out a "Hi, what should we do with this?" to the handful of developers who are still hanging on?
For a lot of reasons, some technical, some not, JMF is a hopeless case. Unfortunately, due to the benefits of incumbency (the prominent
javax.media package), it lures developers into a Venus Fly Trap of minimal functionality and unfixed bugs.
So, Sun, do you want to know what I think you should do with JMF? Deprecate it. Stop wasting our time. Tell everyone you're done and move on to something that might work out better.
What good could come from reviving JMF?
I sure hope you emailed this to that guy, as Sun seriously needs to be told off on this. Sun already screwed the pooch by letting Flash become what it is today instead of Applets; JMF either needs to go away or be made current, and I believe what you said in doubting Sun cares enough to do it.
You missed the big problem completely
It was an interesting post Chris and while I agree with pretty much everything you said I think you missed the biggest problem that JMF and any "media" product faces: Copyright, trademarks and patents.
Its a mess out there, we recently did a project that required AMR support. Our team spent months with the patent holders for some key properties trying to get to a redistribution deal... Its just impossible to support all of these codecs and standards in a big business which is why only the "big" companies that have strong ties to the "industry" have products in this field.
No, don't do it! If JMF mean a wasting of time for Sun, makes what one becomes for all standard as this: It specifies it in the JCP and open it!
We need JMF or at least something similar
Hi, I am steering member of Javapolis
When I developped the player, I was really willing to do it as a Java applet playing and navigating into MPeg4 content.
IBM had a good player, but not free, then there was an open-source player "MediaFrame" that was not stable enough at the time.
At the end, I have selected Macromedia Flash technology to develop the player. That was the first time in 5 years I was dropping Java for a new language.
I must say that I appreciate Flash for what it can do the best. Clearly, video and animations are really easy in Flash.
I do not think Java will ever compete with Flash, it is too late to jump in this bandwagon.
But definitely, multimedia capabilities are lacking in Java. We need at least MPEG-4, MPEG-2 and MPEG-1 video and MP3, AAC audio decoding with a decent API to be able to navigate into and get meta-data from that kind content.
I just started with JMF and I am not unhappy with it. My customers are actually really happy with it.
Try FOBS in conjunction with JMF
I have to say, I struggled with QTJava for a long time, just to get a simple player inside of a more complicated, resizable and proportional layout, to work properly. The movie would always disappear, or the control bar would disappear, or the program would crash, or it would play outside of its bounds, etc. The tricky part was that I needed to load multiple movies into this layout, which is when everything usually went awry. And then don't get me started on QT updates which break everything, constantly. And installers! I do have access to the QTJ book :-)
Hello, I just wrote a speeh to sms j2me programe using j2me.mmapi onf the handset and sphinx4 ( voice recognition ) and FFMpeg for Java bindings theses all support the JMF. Had not the JMF exisited could these two applications talk together? without glass in my food? no. JMF need to support things such as media signing, so say in my case the client licenses the AMR capture codec and then the license to use the AMR deocder on my server also. Why should I pay so they can decode their own content?
|I just wanted to bring attention to our new effort to create an open-source implementation of JMF, (FMJ, fmj.sourceforge.net), which can hopefully address some of the problems mentioned. We are still heavy in the development stage, but are looking for help...|