The Artima Developer Community
Sponsored Link

Java Community News
Rebooting Java Media

2 replies on 1 page. Most recent reply: Jan 3, 2007 8:06 PM by Stephen Graham

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 2 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Rebooting Java Media Posted: Jan 2, 2007 1:31 PM
Reply to this message Reply
User-contributed content has dominated the Web in 2006. Much user-contributed content is no longer limited to text, and includes video and audio. According to a recent blog post by Chris Adamson, that trend poses a problem for Java, as Java has poor support for interacting with rich media types. He proposes that Java's media support needs a reboot.

Time magazine naming you its Person of the Year intended to acknowledge that user-contributed content has significantly transformed the media business already, and will do so even more in 2007.

User contributed content is not limited to text, as YouTube and other outfits built on rich-media have demonstrated. That trend presents a problem for Java, because Java is especially poor at supporting the creation and interaction with such media types, according to Chris Adamson's recent multi-part blog post, Rebooting Java Media (Act I: Setup and Act II: Development).

Adamson notes that media capabilities today must include not just play-back, but also rich interaction with media:

One of the key concepts of Web 2.0 is “the read/write web”. In other words, if Web 1.0 media was just about watching, Web 2.0 should be about creating, modifying, personalizing, and sharing media. Web 2.0 media is “rip, mix, burn”...

The read/write nature of Web 2.0 requires media libraries to offer creative capabilities and not just playback... Desktop Java needs to offer more ambitious functionality to avoid being rendered irrelevant by webapps, Ajax, and Flash.

The problem, according to Adamson, is that Java almost completely lacks viable means of providing user interaction capabilities for rich-media. An example is the Java Media Framework aimed solely at recording and play-back, but not for editing and otherwise modifying media:

All the abstractions [such as] pointer-like media references, tweens, arrangement of tracks ... don’t exist in JMF. In fact, JMF doesn’t have a useful abstraction of media in a stopped state. To JMF, media is something you play, and optionally “process” (e.g., transcode to another format), and that’s about it. The library offers no deep knowledge of media, and no support for the kinds of tasks needed to create and distribute media.

“Rip, mix, burn” is a great metaphor for what people want to do with their media in the Web 2.0 era. And when Apple says “rip, mix, burn”, what you should hear in the abstract is “capture, edit, export”. JMF’s biggest problem is that it can barely do the first (and pretty much only on Windows), and can’t do the second at all.

While cross-platform, network-ready Java was ideally suited to be the king of rich media on the desktop, Flash, Quicktime, and other technologies eclipsed Java in that niche:

The use of Flash for web media has exploded in the last year or so, oftentimes displacing the classic Real/WindowsMedia/QuickTime troika even for basic playback scenarios. The reasons are easy to understand: Flash has better cross-platform distribution than all of them, and can can offer whatever level of interactivity the developer chooses to provide, from a simple “click button to play” to more sophisticated uses, as in the Schmancy Smashup.

Adamson believes that Java must either catch up with those competing platforms in media-handling capabilities, or desktop Java may be relegated to a small niche:

If Desktop Java doesn’t make a stand here, then frankly, where is it going to assert its relevance? Webapps have eliminated many of the use-cases that applets once targeted, and distribution frustrations (among other factors) continue to make double-clickable Java desktop applications a tough sell. Ajax is all but the final insult: at the end of the day, script manipulating UI widgets in a browser isn’t that different than Java bytecodes manipulating AWT or Swing widgets… except for the fact that Ajax is infinitely more popular than any of the Java client technologies ever were.

To what extent do you expect to incorporate rich-media into your applications in 2007? Do you believe that Java's support for user-created rich-media is important?

Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: Rebooting Java Media Posted: Jan 3, 2007 12:48 AM
Reply to this message Reply
I've been working on a Java based system that is all about user generated content, but the two are not good friends. We go with FFMPEG, Flash, Python etc for creating/editing/presenting multimedia since the Java Media Framework has been dead in the water for ages.

The sad thing is that in the early days JMF was top notch. But as with many e-commerce websites before the internet boom it was put on hold and never revived again. I think now it's too little too late, the world has moved on.

Stephen Graham

Posts: 5
Nickname: sgraham
Registered: Jan, 2006

Re: Rebooting Java Media Posted: Jan 3, 2007 8:06 PM
Reply to this message Reply
I work in the film and TV post production industry and have on numerous occasions attempted to implement solutions using JMF, but the effort has always been short-lived and I end up implementing the solution in C++.

Even if Sun decides not to enhance JMF they should at the very least make a clear statement about how they expect us to implement rich media applications. Ideally they could provide good support the most commonly used third party technologies such as QuickTime, DirectX, Flash etc.

Flat View: This topic has 2 replies on 1 page
Topic: Jakarta Project Releases Commons Virtual File System 1.0 Previous Topic   Next Topic Topic: The Big Rewrite: Why So Hard?

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use