Java Reference
In-Depth Information
Caution The boundary between container file formats and data file formats is often a blurry one,
especially when many encodings are themselves containers. When working with content providers, it's not
enough to say something like, “I'll take that as an MPEG-4 file, please,” the way you might ask for a PNG
image. Worse, the coding schemes supported by different devices are often different, so you may find that
an MPEG-4 file that plays on one device doesn't play on another, because the streams of data inside the
file are coded using a compatible codec on the first device (say, in AAC on a device that supports AAC) and
incompatible on the second. Later, I show you how to interrogate a device's MMAPI implementation to deter-
mine just what codecs are available.
Second, content providers can deliver multimedia in files—an all-at-once process in
which the device stores an entire file (say, a song or video) on the device's file system—or
stream data using protocols such as the Real Time Streaming Protocol (RTSP). Most inter-
faces to multimedia systems treat the source of the data as a discrete entity, aptly calling
it the data source . A data source hides all the details of how the device obtained the
encoded data; it may have fetched the data from a file or over the network using any
one of a number of open or proprietary technologies.
Third, the low-level notion of a codec is usually at the wrong level of abstraction for
the average application developer. Working at the application layer, it's easiest to think
of a player : an engine that, given a data source and some information about the how
the data coming from that data source was encoded, can render the data as an audio or
video stream. Players typically either offer interfaces directly for managing rendering,
or, on some platforms like that provided by the MMAPI, provide an interface to obtain
one or more controllers that can control a specific player's rendering of the data from
the data source.
Note Experienced readers will doubtless see parallels between the MVC pattern and the source-
player-controller organization of many multimedia APIs. This is not a coincidence; the division of responsibili-
ties that MVC provides fits well with the work necessary to render a multimedia stream, at least from the
perspective of you and me as application developers.
Finally, while you're likely most interested in rendering multimedia from a data
source such as a web service or file, it's important to realize that today's devices may offer
their own data sources. A camera phone, for example, has an imaging sensor; many
implementations of the MMAPI permit you to treat that imaging sensor as a data source
from which you can render video and even capture images. When thinking about multi-
media applications, it's important to remember that the source-player-controller division
of responsibilities is a general one and can be applied to almost anything that represents
a stream of multimedia data.
 
Search WWH ::




Custom Search