The Processor interface defines a module for processing
and controlling time-based media data.
Processor extends the Player interface.
Unlike a Player, which processes data as a "black box" and
only renders data to preset destinations, a Processor
supports a programmatic interface that enables control over the media data processing
and access to output data streams.
The processing performed by a Processor is split into
three stages:
- Demultiplexing -
an interleaved media stream is first demultiplexed into separate tracks of
data streams that can be processed individually.
- Data transcoding -
each track of data can be transcoded from one format to another.
- Multiplexing -
the separate tracks can be multiplexed to form
an interleaved stream of a particular container content type.
Both the data transcoding and multiplexing processes are programmable.
How a Processor Differs from a Controller
Processor extends the state transition cycle of a
Controller by adding the Configuring and
Configured states.
The purpose of these additional states is to further refine
the realizing process. The
realizing step is essentially split into two phases:
- Source information gathering -
the input
DataSource is queried and the input media
stream is parsed to get the format information for the tracks in the stream.
- Construction -
the internals of the
Processor are constructed to handle
the input media stream.
Between these two steps, you can
program the Processor to perform specific
processing on its media stream.
The states of a Processor are:
Unrealized, Configuring, Configured,
Realizing, Realized, Prefetching,
Prefetched, and Started.
The Configuring and Configured States
While it's in the Configuring state, a Processor
gathers the source information necessary to prepare the Processor to be programmed.
This might involve parsing an input file to access the individual
media tracks within the file, or connecting to a capturing device
to determine its capabilities. A ConfigureCompleteEvent
is posted when the Processor reaches Configured state.
Once a Processor is Configured, you can program
it to perform particular processing on each track or to output data in a particular
format.
Realizing a Processor
When you're done programming the Processor, you call the realize
method to complete its construction.
Once the Processor is in the Realized state, reprogramming
the Processor by calling the TrackControl methods or
the setContentDescriptor method is not guaranteed
to work. This is because reprogramming the Processor might require reconstruction
of its internals.
It is legal to call realize on a Processor while it
is in the Unrealized state.
This causes the Processor to transition from the
Unrealized state to the Realized state. As it does this, it goes through each
intermediate state: Configuring, Configured, and
Realizing. However, when you directly realize a Processor, you miss the
opportunity to program it while it's in the
Configured state--the Processor performs whatever default processing its
implementation specifies.
Deallocating a Processor
Calling deallocate changes the state of a Processor
in the same way as a Controller except that
if deallocate is called while the Processor
is in the Configuring or
Configured state, the
Processor is returned to the Unrealized state.
Programming a Processor
You can control both the transcoding and multiplexing performed by a Processor.
Data transcoding is controlled separately for each track.
The getTrackControls method
returns a TrackControl for each track. You use these
TrackControl objects to specify what processing you want to perform.
The multiplexing performed by a Processor is controlled by specifying
the format that you want it to output. This is done through
the setContentDescriptor method.
A Processor can be programmed while it is in the
Configured state. A NotConfiguredError is thrown
if you attempt to program the Processor before
is configured.
If you do not program a Processor through the
TrackControl methods or by calling setContentDescriptor,
it performs whatever default processing is specified by its implementation.
Getting the Output from a Processor
The processed output data streams can be retrieved from a Processor
through its output DataSource. The output
DataSource provides the gateway for the output data to
be read. A DataSource output from a Processor
can be a PushDataSource, PushBufferDataSource,
PullDataSource, or PullBufferDataSource depending
on the implementation of the Processor.
A NotRealizedError is thrown if
getDataOutput is called on a Processor
that has not yet been realized.
Using a Processor as a Player
Many Processor implementations can be used like a
Player to render media data instead of sending it to an
output DataSource. In this case, the TrackControl objects
provide additional information and control over the individual
tracks to be rendered. When used as a Player, a Processor
does not produce an output DataSource.
To use a Processor as a Player, you call
setContentDescriptor(null). | 