JMF is an application programming interface for incorporating audio, video and other time-based media into Java applications and applets. The current version of JMF is 2.1.1e. It's available for download here.
JMF is very big and complicated. It includes a large number of classes to provide the following functionalities:
- play and stream different types of multimedia file (AVI, MPEG and WAV, etc.)
- capture audio and video data from microphones or cameras
- broadcast, unicast and multicast multimedia data over the Internet.
One of JMF's important design considerations is to support standard protocols. JMF provides these functionalities by working on top of RTP and RTCP.
The architecture of JMF is shown in Figure 1.3. One obvious feature of the architecture is that it contains some native components that talk directly to hardware. These components include the codecs, capturers and renderers. They are responsible for the capturing, coding/decoding and playback of media data. These tasks are intimately related to the hardware, so a native approach can help to boost performance and get around security issues, because Java code is not allowed to have direct control over the hardware of the host operating system. Apart from these exceptions, the core of JMF is implemented in pure Java.
The hardware dependency of JMF creates an inconvenience for JMF applications, however. JMF must be installed on any client machine that runs these applications. This is one reason why JMF has not been very successful so far.
JMF components are designed after the model of media playback as shown in Figure 1.4. This model is familiar to us because it is very similar to the way common electronic devices are connected together - and how they have been for quite a long time. In this fundamental model, a video camera represents a capture device; the media data (a video tape, for example) is encapsulated as a data source; and the VCR, as a player, controls the playback of media data. Finally, during playback, the data is rendered on destination devices such as loudspeakers and a television.
Source: Sun Microsystems 1999, figure 2-1.
In Figure 1.4, the data source represents media such as video or audio objects. Java is an object-oriented programming language, so the DataSource class encapsulates everything required to retrieve the content, including the location of the file (which could be a local file or an Internet link), and determines what protocol and decoder should be used to read the content.
JMF DataSource can be classified according to how a data transfer is initiated:
- Pull data source -- The client initiates the transfer of data, and flow control is done on the client side. For example, HTTP is a protocol for this type of data.
- Push data source -- The transfer of data is initiated by the server, and flow control is also managed by the server. An example is multimedia broadcasting.
Several DataSources (audio, video and text) may be combined to form a single DataSource (i.e. a movie) for easy control. Capture devices are the hardware you use to capture the data. They include microphones, video cameras, etc. You should note that a video camera delivers both video and audio data. Capture devices can also be classified as either push or pull sources. For example, a still camera is a pull source because the user controls when to capture an image. A microphone is a push source because the microphone provides a continuous stream of audio data.
The Player is the component that actually brings the data to a speaker and screen. It is not concerned with how the original data in the data source should be interpreted. This is the job of the DataSource class. Its main function is to control the playback of data, very much like the VCR in Figure 1.4. The data from capture devices can also be fed to a Player for playback. Just as an ordinary VCR can have different states (stopped, playing, paused, etc.), a Player also has a number of states. There are six states defined for a Player; the interactions between these states are shown in Figure 1.5.
The meaning of each state is briefly explained here:
- Unrealized -- The Player has just been created, and knows nothing about its media content.
- Realizing -- The Player is determining the resources requirements of its media content.
- Realized -- The Player has already worked out the resources requirements of its media content.
- Prefetching -- The Player is preparing itself for data playback.
- Prefetched -- The Player is now ready to start playing.
- Started -- The Player is playing the media content.
Below is a simple example of the Player class in practice:
import java.net.*;
import javax.media.*;
import java.awt.*;
public class JMFAudio extends Applet{
Player player;
public void init() {
try {
URL url = new URL(getCodeBase(), "a.mp3");
// create a player using the url
player = Manager.createPlayer(url);
}
catch (Exception e) {
System.out.println(e);
}
}
public void start() {
player.start();
}
public void destroy() {
player.stop();
player.close();
}
}
Download a.mp3
As you can see, it is not very complicated. To use the JMF classes, the package javax.media* has to be imported. The Manager class is a factory class that handles the construction of other objects in JMF. In the init() method of the applet, a Player is instantiated, using Manager, with the given URL of the audio file. In the applet's start() method, the player is started. By calling the start() method, the player is implicitly asked to go through all the states listed above until the Started state is reached. When the browser unloads the applet, the destroy() method is invoked, in which the player is stopped and closed. It is important to close the player to ensure that the audio hardware is released.
- 6253 reads
