PlugIns

PlugIns are a powerful feature of the JMF that allow fine control over the processing of media. Fundamentally, as shown by Figure 8.22, the PlugIn model breaks processing into five component stages that can be chained together.

The components that correspond to each of these five stages are

Demultiplexer— Splits media into its constituent tracks

Codec— Compresses or decompresses a media track

Effect— Performs special effects processing on a media track; a generic category for any form of manipulation of the media data

Renderer— Plays (renders) a media track such as video to the screen or audio to speakers

Multiplexer— Combines media tacks into a single media stream

These forms of processing are discussed in greater detail, but independent of the JMF, in the previous chapter.

Processors (discussed in the next section) that support TrackControls allow the specification and order of the PlugIns. The PlugIns' order will operate on the individual tracks that compose a media item. Thus, the PlugIn model provides a programmer with fine control over the processing performed on media. Indeed, as discussed in Chapter 9, programmers can write their own classes that implement the various PlugIn interfaces.

One hindrance is worth mentioning here: It isn't mandatory that PlugIns be supported in all JMF implementations. Although the current implementations of version 2.1.1 (Sun reference, Windows performance, Solaris Performance, and Linux performance) all support PlugIns, it is possible that some future implementation might not. As an example, this could be the case with a JMF implementation for mobile computing (that is, mobile phones and PDAs) in which resource constraints are tight.

As shown in Figure 8.23, the PlugIn interface is relatively simple. All key functionality lies in the Demultiplexer, Codec, Effect, Renderer, and Multiplexer interfaces that extend PlugIn. Hence, a PlugIn is a generic processing unit that accepts media in a particular format and processes or presents that data. The open() and close() methods serve to prepare or terminate the PlugIn activity and acquire or free the resources required by the PlugIn, respectively. The reset() method resets the state of the PlugIn, whereas getName() returns a human-readable String defining the name of the PlugIn.

PlugInManager

Given the potential plethora of PlugIns, it isn't surprising that the JMF provides a manager class, PlugInManager, for maintaining a register of all PlugIns that can be both queried and altered. Figure 8.24 shows the methods and class variables of PlugInManager. As for the other manager classes, all methods are static (invoked using the class name).

PlugInManager finds particular use in those situations in which the list of PlugIns is being altered. It will be discussed more in Chapter 9, which deals with, among other things, extending the functionality of the JMF.

PlugInManager can also be used to query what PlugIns are available. The getPlugInList() method returns a Vector of PlugIns that are of a particular type (for example, PlugInManager.CODEC), support a particular input format, and produce a particular output format. Alternatively, given a particular PlugIn, the getSupportedInputFormats() and getSupportedOutputFormats() methods can be employed to discover what Formats the plug-in in question supports.

Demultiplexer

The first PlugIn in any processing chain is a Demultiplexer. Its task is to separate a media stream into its individual tracks. Hence, it has a single input and multiple (the number of tracks) outputs.

The Demultiplexer plug-in extends the PlugIn, MediaHandler, and Duration interfaces; in addition, it defines the methods as shown in Figure 8.25.

The single most important method of the interface is getTracks(), which returns an array of Track objects. This method might either throw a BadHeaderException (if the header information in the media is incomplete or inappropriate) or an IOException. The start() method must be called before Track's readFrame() method will be called on any of the Tracks returned by getTracks(). The stop() method should be called when no further Frames are to be read.

The interface also provides a number of informative methods: Among these is getSupportedInputContentDescriptors(), which returns an array of ContentDescriptor objects that are supported by the demultiplexer.

Codec

A Codec is a PlugIn that performs processing on an input Buffer and produces an output Buffer. This is a surprisingly broad definition because a codec is typically understood to be a compressor or decompressor: a processing unit that converts from one format to another. However, the JMF Codec interface is more encompassing: Any form of processing from input Buffer to output Buffer falls under the category of Codec (although see the next subsection on Effects).

Codec extends the PlugIn interface and thus includes all its methods. Figure 8.26 shows the methods of Codec itself. Codecs work in one of two modes known as frame based and stream based. Frame-based codecs can handle data of any size: Each processing call results in the consumption of the input Buffer and the production of an output Buffer. Stream based Codecs don't have the same synchronization between input and output Buffers. Each processing call might result in only a portion of the input Buffer being consumed (processed). Alternatively, an output Buffer might not be produced after each processing call.

The key method of the class is process(), which accepts an input Buffer and returns an output Buffer as a parameter. The supported input and output Formats of a Codec can be queried, whereas the particular Formats to be employed for input and output can also be set through the methods of the class.

Effect

The Effect interface is an empty interface that extends Codec: It represents objects that process media data in Buffers but don't alter its Format. For instance, an audio Effect might add reverb to a media track of a particular, or a number of, format(s).

Hence, the Effect interface possesses all the methods of Codec, but no others.

Renderer

The Renderer interface defines a processing unit that renders (plays) a single track of media to a predefined device such as the display or speakers. Being a final link in the processing chain, it has a single input and no outputs.

Figure 8.27 shows the methods of Renderer. The single most important method is process(), which is provided with a Buffer that must be rendered. The start() method initiates the rendering process, whereas stop() halts it. The Formats supported by a Renderer can be queried, whereas the particular Format to use in order to render can be set through the appropriate methods.

Multiplexer

The Multiplexer interfaces define a processing unit that combines one or more (typically more) media tracks into a single output content type (ContentDescriptor). The interleaved tracks are available as an output DataSource object.

Figure 8.28 shows the methods that the Multiplexer interface adds to PlugIn. Although, as with other PlugIns, the process() method is central, several other methods are also vital to achieve any multiplexing task. The process() method is provided with a Buffer that corresponds to a particular track number. Setting up a Multiplexer requires informing the Multiplexer of the number of tracks (using the setNumTracks() method) and the format of each of those tracks (using the setInputFormat() method), as well as specifying the required output content type (using the setContentDescriptor() method). The resulting DataSource is obtained with the getDataOutput() method.

The following psuedo-code shows the typical steps involved in using a Multiplexer.

Set the output ContentDescriptor
Set the number of tracks
For each track
       Set its format
while there is more data to multiplex
       for each track
              Process that track's current Buffer
Get the output DataSource