Aug. 22, 2007, 5:57 a.m.
posted by barateon
Enhanced Media Support Using the Mobile Media APIAs discussed earlier in this chapter, MIDP Sound API is a subset of the Mobile Media API (MMAPI) defined by the Java Community Process effort JSR 135. MMAPI includes a lot of additional functionality that is not present in the MIDP 2.0 Sound API. The additional features introduced by the Mobile Media API include the following:
The scalability and optional use of the API is crucial for the successful deployment of the API in mobile devices. It is clear that not all implementations of MMAPI will support all multimedia types and input protocols. For example, some of the devices may support only playback of local audio files. The design of the MMAPI allows implementations to provide optional support for different media types and protocols. As with the MIDP 2.0 Sound API, class Manager provides the getSupportedContentTypes and getSupportedProtocols methods to query for supported media types and protocols. An application can also attempt to create a Player from class Manager given the media input. If the content type or the protocol specified is not supported, the Player creation methods will throw an exception. Because MMAPI is an optional package, it does not mandate any particular media types or protocols. Required types and protocols are to be determined by the appropriate profiles adopting MMAPI (for example MIDP 2.0). However, an implementation must guarantee support of at least one media type and protocol. MMAPI also allows implementations to support optional features. For example, some implementations may support only media playback but not recording. MMAPI allows implementations to expose these optional features as applicable. Optional features are organized as Control classes. A Player can be queried for all of its supported Controls using the method getControls or a particular type of Control using the method getControl. MMAPI mandates support of some features for some media types. Other features are recommended while others are entirely optional. This guarantees some uniformity across different implementations. The implementation alternatives are categorized into features sets. When a Player is created for a particular type, it must follow the guidelines given in the specification and implement the appropriate Control types. The following feature sets are defined for five different types of media:
1 DataSourceClass DataSource encapsulates protocol handling. It hides the details of how the data is read from its source, and whether the data is coming from a file, streaming server, or a proprietary delivery mechanism. Class DataSource provides a set of methods to allow a Player to read data. 2 Advanced ControlsMMAPI defines a total of 12 Control classes. These Control classes are summarized in Figure.
The ToneControl and VolumeControl interfaces are specified in the MIDP 2.0 Sound API. For video and camera functionality, FramePositioningControl and GUIControl are provided. MIDI specific controls include MIDIControl for controlling a sound synthesizer using MIDI messages, PitchControl for changing the pitch in music applications (such as Karaoke), RateControl for changing the playback rate of a player, and TempoControl for controlling the playback tempo of a song. Additional controls include MetaDataControl, which allows the addition of auxiliary data related to a media stream, and StopTimeControl, which allows for setting a preset stop time for playback. The set of controls in the MMAPI specification provides a versatile means for creating audio, MIDI, video, and camera support in MIDlets. In future releases of the API, new controls may be introduced. |
- Comment