The JMF is a set of three new APIs being co-defined by the JMF Working Group members -- Sun, Silicon Graphics, and Intel. These APIs eventually will include Java Media Player, Capture, and Conferencing. The first to be delivered, the Player API provides a framework for implementors to build media players and provide them in a standard way on all Java platforms. The JMF specification is flexible enough to allow developers to extend players by adding their own nodes (such as images filters, audio reverb effects, and so on) or to use the standard players without making any additions.
Before the JMF Player API, multimedia playback support in Java was extremely limited. Programmers had to generate their own GUI controls. (JMF returns a standard set of controls in the form of a ControlPanel and other Control objects.) The supported media types in the core Java API were limited (Sun's muLaw format for sound, and no media option for video), so developers were forced to implement their own players without any underlying framework to assist them.
With the JMF Player API, however, Java programmers can implement support for almost any audio or video format by building upon an established media playback framework. In addition, standard implementations (see Resources for URLs pointing to more information on implementations from Intel, Silicon Graphics, and Sun) provide built-in support for common Web formats such as muLaw, Apple AIFF, and Microsoft PC WAV for audio, as well as Apple QuickTime video, Microsoft AVI video, and Motion Picture Expert Group's MPEG-1 and MPEG-2 for video. MIDI currently is supported in the Silicon Graphics IRIX implementation and is slated for support in Intel's Windows implementation. If you want to use one of these standard Web-based formats, you are now able to easily integrate multimedia playback into applets and applications alike with only a few lines of code.
JMF allows player implementors to use native methods as need be underneath the covers for greater speed. This lets the implementors optimize performance on each platform. At the same time, the common Java Media Player API ensures that applets and standalone applications will run on any Java platform.
Installing JMF softwareInstallation of the JMF software is straightforward. You need only download a package containing the classes, documentation, and accompanying files for your platform and install it using the standard method.
Implementations currently are available from Silicon Graphics and Intel for IRIX and Windows 95/NT, respectively. Sun currently is working on a Solaris implementation. Note that you can use JMF with Sun's Java Development Kit (JDK) or with a browser. Implementations that work for Netscape Navigator 3.01 are available on all platforms, and Intel's Windows 95/NT implementation also supports Microsoft Internet Explorer 3.01.
Using a player
Java Media players support a six-state model based on the two fundamental states Stopped and Started.
This model is outlined in the accompanying state diagram, with Stopped states given in green and the Started state in white. The states are Unrealized, Realizing, Realized, Prefetching, Prefetched, and Started. Note that the transitions from Realizing to Realized and Prefetching to Prefetched are automatic (Realizing and Prefetching are transient states of indeterminate length). Other transitions are brought about by method calls, with some of the most important methods being given in the diagram. 
State transitions are accompanied by the appropriate TransitionEvent being generated. Any interested class can implement the ControllerListener interface and use its controllerUpdate method to handle such TransitionEvents accordingly. A complete listing of TransitionEvents is available in the JMF Player API Documentation.
A JMF player fundamentally is an encapsulation of the multimedia component that allows for control of state transitions during playback. JMF players provide methods to query the current state, to acquire necessary resources, and to start, stop, and control the actual playback of the media file or stream. Read on for a brief description of how to create a player and control it.
java.media.Manager uses the media sample's URL to build a player using a PlayerFactory. This factory model is very similar to the Connection Factory used in JDBC and similar to other factories used throughout the Java APIs. The Factory itself uses appropriate protocol handlers and content handlers to build and return the final media player. A player is built and returned as:
After being returned from the PlayerFactory, a player must be "Realized" and "Prefetched" before it can be started. Realization refers to the process of finding all resources the player will need to play, whereas prefetching actually loads the resources and readies the player to begin playing. Each of these state transitions are completed by making one call to the Player API. Note that the realize method is a non-blocking method, but that players need to be realized to use many of their methods (such as getVisualComponent, for example), so it is often useful to implement a blockingRealize yourself for use in guaranteeing that you have a realized player. This example blockingRealize works in cooperation with the controllerUpdate method and a boolean variable to ensure that a realized player is returned.
boolean realized = false;
public synchronized void blockingRealize() {
myPlayer.realize();
while (!realized) {
try {
wait();
} catch (java.lang.InterruptedException e) {
status.setText("Interrupted while waiting on realize...exiting.");
System.exit(1);
}
}
}
public synchronized void controllerUpdate (ControllerEvent event) {
if (event instanceof RealizeCompleteEvent) {
realized = true;
notify();
} else if (event instanceof EndOfMediaEvent) {
eomReached = true;
}
}
Once prefetched, a player has the necessary resources to begin playback. A call to the start() method begins playback at the beginning of the media sample or the appropriate point in a live multimedia stream. Note that if start() is called on an Unrealized player, the player first uses its realize() and prefetch() methods before starting. Similarly, calling start() on a realized player that is not yet prefetched will result in prefetching occurring before starting.
