Mason Glaves's Blog

JMF, wherefor art thou?

Little known to most people who've tried to put a JMF application together is the fact that it seems to now be completely unsupported by Sun. Admittedly, it's a tough API to code for. Codecs are almost unanimously covered by restrictive copyright and royalty agreements, and those that Sun could round up to implement require a great deal of processing power (not to mention the interface with the low-level audio and video hardware) to fully utilize, something that isn't really a strong point for the Java language. Yet, despite these roadblocks, the initial reference implementation looks remarkably promising... and that's where it all goes down-hill.

The remarkable ease and usability of the initial implementation gets you interested. The implementation, especially for a very limited and specific set of codecs, hardware and other intricacies, works beautifully. As there is no obvious indication that the API is no longer really supported by sun, it's also easy to believe that the next version, whenever it comes out, will have that one extra feature that you are looking for.

Reading the JMF-INTEREST mailing list show how many have fallen into this trap. If you've got a six-month project, and you only need one small addition, or one small bug-fix to JMF to complete it on time, it's fairly easy to assume that by the time the release date comes around, you'll have the next release of JMF and will be ready to go.

The next release is not coming. From the chatter on the list it has become more and more obvious that Sun has quietly abandoned JMF, but isn't willing to let the general population know about it.

Well, that's fine, because Sun's reference implementation of JMF is just that, a reference implementation... somebody out there has to be writing a commercial-quality implementation of the spec, right? Well, ignoring the fact that people are perfectly happy to use the reference implementations of Java APIs in production environments (Tomcat, for example), the answer is no... There are currently no implementations that I (or anyone I've asked, including Senor Google) am aware of.

Why is that? Well, it's just pure speculation on my part, but I'd say that's because Sun's RI does too good a job for you before you discover that it fails. If your software company were to begin the project of writing a full-scale implementation, the first thing you'd do is look at your competition, namely Sun's JMF. You'd see that it looks, from the quick, once-over perspective, to be fully functional. It'd appear to you to be a long and unpleasant road ahead of you to “beat” the freely available RI. This is especially true if you were led to believe that JMF is under active development, a misconception that's very easy to believe if you're just casually looking into JMF. There's not a great deal of incentive to ever start down that road, so you'd back off and turn to more fruitful options.

At this point Sun really needs to consider taking action. Either they need to begin active development on the RI again, or they need to come out, officially, and tell the world that they have dropped support for JMF's Reference Implementation. They could sit on the code, or present it to the Open Source community for further development.

Either way, an open statement to the demise of the implementation would do a world of good for everyone involved. It would let people know, before they ever get the idea in thier head, to be wary of complicated Java-based multimedia projects using JMF. It would allow either the open source community or private commercial entities to take up the torch and begin developing true JMF implementations of thier own without having to fear "competition" from Sun.

So, how about it, Sun? Where is JMF going from here?

Comments

• Wow, I

  Posted by: armhold on April 11, 2005 at 03:51 AM

• Wow, I'm glad someone finally stood up and said it. 2 years ago
  we started a project based on JMF. We needed a library for
  synchronizing audio with various "slide show"-like actions. That is a
  move I deeply regret. JMF is abandonware. We are in the process of
  slowly coding our own (simple) version of timeline management and
  synchronization, with an eye towards eventually replacing JMF.

  JMF was a nightmare to work with. Even if you decide to download
  the source, good luck trying to build it. A twisted maze of Makefiles
  and platform-specific C code. Half of the "source" is proprietary
  binary-only code anyway. The examples listed on their website are
  full of typos (try using TimeLineController.java- it contains a
  misplaced "}" that causes an infinite loop!)

  There really is a great need for an updated JMF, or even a modern
  replacement. Without such a library, multimedia on Java is really not
  going anywhere. Sun- please at least put a note on the JMF page
  saying that it is no longer under development. This way perhaps some
  bright people will band together and decide to implement something for
  the good of the community.
  

  Posted by: armhold on April 11, 2005 at 03:53 AM

• I've known enough all along to not bother with JMF. You might check in with Sun guys Chet Haase, Doug Twilleager, or others in the Java Gaming community here on Java.net and see if they have any solutions besides JMF.

  Not sure if this helps, but aren't there some Flash/Java integration projects? As far as I know Flash supports audio/video playback, and if it's mostly just a slideshow type app without much else, doing the whole thing in Flash with ActionScript might be a better way to go, and probably cross-platform enough, too. Macromedia Flex is supposed to be really cool, too. Bummer that it ain't free like Java, though.

  If you find a good alternate solution or get a response from Sun, post another item about it.

  Posted by: gerryg on April 12, 2005 at 01:39 PM

• Hi Mason, thanks for the great feedback. I work in the Java Client Group (I manage the Swing team), and wanted to say that your timing is great, in that we just took ownership of the Sound and JMF apis this past week. We're currently hiring a sound engineer, and we're discussing how to proceed with JMF - indeed, we really want your opinions on some ideas we have. Please stay tuned, we hope to say more about this in the very (very) near future.

  Posted by: jdinkins on April 12, 2005 at 02:08 PM

• gerryg,

  Thanks for the advice, but flash wouldnm't really work, at least in my situation. What I'd really like is lower-level programattic access to the v4l api (tv tuner, especially). :) Of course, I've already found a workaround but it's very unstable.

  Posted by: mason on April 12, 2005 at 05:55 PM

• jdinkins,

  I'd love to help out any way I can. I've been doing some pretty graphics intensive things, and trying to use JMF where I can, but it's been proving to be quite a challenge. Unfortunately, I'm not sure if I am a great test subject, though. I tend to need completely different things than most JMF users (for example, I primarily need to use and capture from the tvtuner. The thing that would help me more than a basketfull of new codecs is simply video-overlay from the tuner straight to the video card, i.e. to reduce the CPU usage from 99% to nearly 0%... but I have a feeling that this is a feature only required by a very small number of users).

  I'm VERY glad to hear, however, that someone has picked up the torch with JMF! Already I have great hopes that I won't have to abandon my Java solution for somonething less elegant and flexible.

  Posted by: mason on April 12, 2005 at 06:02 PM

• Abandonware. I like that.

  javax.sound happens to be adequate for what I need, which isn't much. There's all too much abandonware in the Java universe, though. I've complained a few times about javax.comm, which is in a similar state. Nicest serial programming environment I've ever seen... but not all of it works; it never got ported to Linux (though there's the RXTX project), or the Mac. And what about USB? Plenty of great devices to talk to, no APIs to do it.

  Starting an API and never finishing it just isn't responsible engineering.
  

  Posted by: mikel on April 12, 2005 at 06:39 PM

• ouch, the gig is up - and that's too bad. but first check out IBM's MP4 player, which uses JMF and their own framework.
  the problem with JMF was that is was always a dollar short and just a little too late to "keep up" with the commercial change in MP4's for instance. never mind some limitations went it came to writing QuickTime movies (although it was a LOT better then Mac's version of Java media platform).
  Too bad, cuz JMF could have gone somewhere. But I would put money on this thought: put the new java.util.concurrency stuff into a rewrite of JMF and you'd have something. (That'd be a good idea for a new project (hint, hint)

  Posted by: louis14 on April 12, 2005 at 09:43 PM

• Actually, new codecs don't interest me all that much. There will always be newer and newer codes, and those kinds of things can be written by open-source developers without a lot so fuss. What I'd like to see, however, are:

  A step by step guide to JMF codec porting. Take, say, vorbis and theora (both free, open source codecs based on the OGG stream). Walk through step by painful step on how to turn the written spec into a JMF codec. Once this document is written, then open source developers who may not bee 100% familiar with audio and video codecs can at least begin contributing to the project. I'll wager in a very short time JMF will have more codecs available for it than any other player around.
  Hardware. I'd LOVE to see JMF start to take advantage of media hardware, like MPEG encoders/decoders, tvtuners, direct-drawing hardware (JOGL, is REALLY moving along), mixer board, whatever is out there. Take the open-source mplayer, for example. It can play just about *anything* around. and has a million and one different input/output varieties.

  I guess what i'd like to see is it be possible to create a FULL Tivo(PVR)/Media/DVD/foo-player(mp3, mpeg, etc)/etc(video-in, live videoconferencing, whatever) application witten in 100% java. I'm not saying that it would have to be actually written and complete, I just mean that it would be a task capable of being done it in java. That would really turn some heads.
  

  Posted by: mason on April 12, 2005 at 10:06 PM

• mason:
  The JMF framework having codecs is really the most important thing around; right now you really have to look for a move to actually play on the darn thing. And build-it-and-they-will-come has a way of not applying to Java.
  I suggest to check out things like:
  http://fobs.sourceforge.net/documentation.html which does a lot of what you ask for already.
  Last; I actually have been building a full Java TiVO replacement. It works great, with recording, playback, remote-control and all sorts of features (and a great UI as well). After doing it I'm just more and more convinced that Java has a long way to go before I dare call it mature.
  I'm looking at gstreamer-java-bindings as a replacement for me calling xine via Runtime.exec().

  Posted by: zander on April 13, 2005 at 01:01 AM

• Multimedia content delivery on the internet is the imediate future. portals and small scale website will have to incorporate either live video, VOD type video and audio to stay competetive. i cant see why sun wont push java multimedia with full power ahead.

  jdinkins, we are egerly awaiting JMF announcments and we all hope you can clarify some of the fog around JMF.
  thanks.

  Posted by: gkatz on April 13, 2005 at 01:54 AM

• 
  First I am spanish (sorry for my english).

  The las year I knew JMF and I tried realiced a little project to university. First I began with many ilusion to realized a little examples and .... But at the end, I am some angry because I discorver that JMF is a fortget for SUN, (and worse to IBM, that dont contribute to JMF but created a codec for view MP4, and for create MP4 video for many $ $ $ $).

  In this moment a finish a little progran to a work in the university, but if SUN don't work in a new version of JMF, I will try working with other languajes.
  

  Posted by: jtintin on April 13, 2005 at 04:41 AM

• I began with JMF 1.0. While buggy, it allowed me to do what I was required: provide an interactive applet that played and then provided frame-by-frame interaction for users.

  All of the workarounds we had to put in at that time are no longer necessary. JMF 2.1.1 runs cleanly for us. We only use the all-java implementation so that our users need not install anything (except Java) to use our package.

  I understand that the IBM MPEG-4 issue has been crippling licensing terms from the patent holders.

  Now, H.264 changes that and improves on MPEG-4.

  The one remaining problem I have with JMF is that I must use the rather inefficient (in file size) Cinepak codec. I don't even know whether an all-java H.264 can decode in real time on ordinary computers, but I am hoping so and looking for an H.264 capability in JMF.

  My very small company (3 people) does not have the resources to create this codec ourselves. We can pay a modest license fee to someone who provides it ready to go and 100% Java.

  I hope that jdinkins speaks the truth about JMF finding a home in Sun. If you're reading this, please put H.264 on your list. You'll be helping lots of underserved children learn science.
  

  Posted by: hekeller on April 14, 2005 at 06:29 AM

• I am chocked !!! I think JMF is a hell of a framework, and I have been studying audio, video, codecs, formats, processors, datasources, etc. for the last 2 years. I took me a long way to start coding my own JMF programs. JMF is black magic !!! No books, nothing on google, no tutorial and JMF Solutions make sence only to their authors. Well I have this product for distance learning and training with audio and video conferencing based on JMF. http://www.lohis.com.br/. This thing has worked greatly and overcome all my expectations. But now I am scared! Should I go back writing JNI stuff for capturing ???? waveinhandle and stuff like that ??? Noooooooooooooooooo!

  Posted by: saoj_brasil on April 19, 2005 at 05:48 PM

• Check what JMF can do for you here: http://www.lohis.com.br
  

  Posted by: saoj_brasil on April 19, 2005 at 05:49 PM

• This article is picked up at javalobby.org and
  my views are on this thread:

  Should JMF be revived?

  Posted by: rexguo on April 26, 2005 at 08:27 PM

• can any one help me to get a codec(should be good one plz) for my apps ??? i m looking a few of them but not satisfied yet ??

  Posted by: gripusa on July 06, 2005 at 12:54 AM

• I am the CTO of two companies involved in mulitmedia client development. I am attracted to the idea of JMF because of the obvious platform independence. It seems to me that the major problem is that the MM platforms are already pretty confused (Quicktime, DirectShow, et al) - for example, DirectShow has now come out of DX and been moved to the Windows Platform SDK, and there is a confusing overlap between DS and Windows Media. I feel strongly that the best suggestions above are:

  Make JMF open source (LGPL) - I'd be glad to help
  Clearly document techniques for creating extensions
  Let Sun make a clear statement of what it is going to do!

  
  I am attracted to the 'thin skin' approach, because why reinvent the wheel? The downside is that it must be updated every time the underlying architecture changes (new version of QT or DS). To greater extent this is what QT for Java is - maybe there should be a DS/DX/WM for Java? (then what about Linux?)

  There is clearly a need for a stable, supported mulitmedia solution for Java if it is ever going to becoming a standard for desktop apps, more and more of which have some MM component.

  Posted by: alan_at_tcc on July 23, 2005 at 03:59 PM

• Hi hekeller,

  We do can license you java code for the H.264 decoder. you can contact me on mohant_1979@yahoo.com

  Posted by: mohant on August 05, 2005 at 12:22 AM

• Hi everyone,
  it's almost November now. Are there any news?

  Posted by: exactt on October 25, 2005 at 09:51 PM

• Hi

  JMF on Windows allows the use of many of the codecs that are registered with the OS. I use (with JMF) the following:
  - DivX 4.12 (Later versions do not work problem is documented on Sun's JMF pages)
  -XviD all versions so far
  -MP42 (Microsoft)
  -3IV2
  -I263
  -HFYU

  So special codecs for JMF are not required, but we do need JMF to be further developed.

  Dave
  

  Posted by: dmgaskin on November 22, 2005 at 03:02 AM

• I invite anyone interested to check out FMJ, a new open-source project to implement/replace JMF, at http://fmj.sourceforge.net/.

  
  We are still heavy in the development stage, and are looking for contributors.

  Posted by: kenlars99 on May 24, 2006 at 03:10 AM

• Hello to all those reading.

  We have a page about JMF on coderslog, check it out. The site itself is a resource on large scale java application building and also contains information on common\useful configurations.

  JMF

  Posted by: screenedtwenty on June 01, 2007 at 05:21 PM

This work is licensed under a Creative Commons License.