Techno Satish: A Mistake Asking to Be Re-Made

JMF: A Mistake Asking to Be Re-Made

listen

Tuesday December 13, 2005 6:02PM
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
Microsystems.
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
working properly.

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?

Comments

Hear hear!
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.

hexghost | December 13, 2005 06:43 PM

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.

So essentially the main problem is a legal rather than a technical problem and none of us (engineers) can solve it, or can we? We solved our problem by using QT4J but this eliminated Linux/Unix as a potential platform for us...

I raised a solution for this problem in my (old) blog a year or so ago http://jroller.com/page/vprise/?anchor=jmf_is_dead_jdic_should
in essense what I say in the entry is that we should rely on the fine work done by the teams at Apple, Real, Microsoft and MPlayer (or any other Linux/Unix player) by providing a reasonable API to interface into these tools. I think JDIC is the perfect vehicle since it allows Sun to maintain its "distance" from potential lawsuits that might follow.

Anyway we both definetly agree that JMF is dead and should stay dead, I do think that Sun needs to do something in this area though. Since most of us can't rely on QT4J if only for the reason of its limited platform support.

vprise | December 14, 2005 06:22 AM

deprecate? No!
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!

Copernico | December 14, 2005 06:44 AM

We need JMF or at least something similar
Hi, I am steering member of Javapolis http://www.javapolis.com. We have started last year to publish on the web videos of the Javapolis conference and will do the same this year.
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.

mulkers | December 19, 2005 02:22 AM

dont stop
I just started with JMF and I am not unhappy with it. My customers are actually really happy with it.

Deprecation would make me wanna cry. I am currently using JMF in an applet. Pictures can be taken by means of capturing a frame. Installation and detection of devices goes remarkeable smooth. Also installing a VM goes well these days, the size of the VM is not a problem (dutch bandwidth). It is actually the first time for me that an applet adds something that could otherwise not be achieved. Maybe with flash but who wants to use that? I dont!

I am cool with java but the icing on the cake would be hot swap enhancement. A discussion about this on http://forum.java.sun.com/thread.jspa?threadID=572396&tstart=0

Anybody that agrees, pleas vote for it on http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812

Dennisb | December 29, 2005 12:53 PM

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 :-)

With JMF, it all worked the first time, without any hacks required, other than FOBS. FOBS is a JMF plugin which allows you to use FFMPEG, which supports all sorts of current formats.

http://fobs.sourceforge.net/

JMF also seems to me to be a very elegant, event-driven framework with good documentation. It can all be plunked into a single installer. Neither can be said about QTJ.

Plus this works on Linux, as well as Mac and Win.

So don't get me wrong - I do all my work on a Mac, but JMF was much better for the seemingly simple tasks I needed it for. I know it's not as powerful as QTJ when it comes to editing, but all I wanted was a reliable player!

Also, what was the problem with detecting a stopped state? I had no problems with that.

DiehardMM | January 9, 2006 02:42 PM

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?

http://cmusphinx.sourceforge.net/sphinx4/
http://ffmpeg.sourceforge.net/index.php
http://www.mofokom.biz

Warren Crossing | February 22, 2006 07:55 PM

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...

Ken Larson | June 2, 2006 05:44 PM