symba (779893), страница 10
Текст из файла (страница 10)
Now,let’s have a look at a simple example – playing an audio file while noother application is using or attempting to use the audio device. Thefollowing sequence of actions occurs:1. The user starts a player application and chooses to play an MP3 file.2. The play request is forwarded to the controller framework by theaudio client utility that the player application invokes.3. The controller framework loads a controller plug-in that handles MP3files.4.
The controller plug-in reads the data from the source (a file, memoryor a URL).5. The controller plug-in performs any processing required to extractbuffers of compressed5 audio data from the source and pass them toa data sink (in this case, DevSound) continuing until the applicationstops the playback or the end of the file is reached.5 In some devices, the data may be decoded by an MMF codec plug-in before beingpassed to DevSound for playing. This is no longer recommended, but the codec plug-insfor some formats may still be available for use by third-party developers on some devices.266.MULTIMEDIA ARCHITECTUREA codec in the DevSound layer decodes the audio to a raw PCM(pulse-code modulation) format that can be played by the audiohardware.In the case of audio recording, the data flow would be in the oppositedirection. The user chooses to record to a file and either the user orapplication selects an appropriate compressed format, such as AdaptiveMulti-Rate (AMR).
As before, a client utility is invoked, which causesthe controller framework to load the appropriate plug-in. The plug-inthen sets up DevSound for recording. The audio hardware converts theincoming sounds to PCM and they are then encoded to the compressedformat within DevSound. The compressed data is passed back to the plugin, one buffer at a time, where it is written to a file with any necessaryheaders added.For the application programmer, the MMF provides APIs that abstractaway from the underlying hardware, thereby simplifying the code neededto play and record the supported formats.MMF Client-side APIsThe MMF provides a client API consisting of several interfaces that simplifythe interaction with the underlying plug-ins, enabling the applicationwriter to easily manipulate audio and video features. The client APIs alluse the Observer design pattern.
You have to both instantiate the utilityclass and implement an observer interface to receive asynchronous eventsfrom it. The features made available by the client utility APIs are:• Audio playing, recording, and conversion – An interface consistingof three classes (and their respective observer classes); CMdaAudioPlayerUtility, CMdaAudioRecorderUtility, and CMdaAudioConvertUtility. These classes provide methods to create,play, and manipulate audio data stored in files, descriptors, and URLs.• Audio streaming – An interface consisting of two classes; CMdaAudioInputStream and CMdaAudioOutputStream. These classes are a thin wrapper over the DevSound layer that provide extra buffermanagement functionality for client applications.• Tone playing – An interface consisting of a single class CMdaAudioToneUtility. This class provides methods for playing andconfiguring single and sequenced tones as well as DTMF (Dual ToneMulti-Frequency) strings.• Video playing and recording – An interface consisting of two classesCVideoPlayerUtility and CVideoRecorderUtility.
Theseclasses provide methods to create, play, and manipulate video clipswith or without audio tracks stored in files, descriptors, and URLs.MULTIMEDIA SUBSYSTEM27Note that these interfaces are generic and developers cannot rely on allof the functionality being available on a particular device. For example,playing audio from a URL is generally not supported and recordingaudio or video to a URL has not been implemented by any manufacturereither.
Additionally, the existence of two audio codecs on a deviceis not sufficient to ensure that the CMdaAudioConvertUtility canconvert from one format to the other. Developers should always checkthe supported functionality on their target devices before planning to usea specific function.The client APIs can be roughly split into two types; the first type areAPIs that deal with clips. In this case, the MMF controller is responsiblefor reading the media data from or writing the data to the clip.
The clipmay be passed to the APIs by filename, URL or directly in a descriptorfilled with data.The second type are streaming APIs that do not deal with clips. Theyallow a client to pass audio data into the API or read data directly from it,bypassing the controller framework. The audio data is streamed into andout of the API, it is not ‘streaming’ in the sense of streaming data over anInternet connection.MMF Controller FrameworkThe controller framework is a framework for specific multimedia plug-inscalled controller plug-ins.
A controller plug-in’s main role is to managethe data flow between the data sources and sinks. For example, an audiocontroller plug-in can take data from a file – the source – and output it toa speaker – the sink – for playback. It could take data from a microphonesource and save it into a file sink.It’s possible for a controller plug-in to support multiple media formats.For example, a single audio controller plug-in may support WAV, MP3,and AMR formats. This is possible since each controller may use multiplecodecs, either as separate plug-ins or via direct support for them in theMedia Device Framework (see Section 2.4.2). More typically each formathas a separate controller plug-in.More information about the MMF controller framework can be foundin Chapters 4 and 5.2.4.2 Media Device Framework (MDF)The Media Device Framework (MDF) is the layer below the controllerplug-ins. It provides a hardware abstraction layer that is tailored to eachhardware platform on which the MMF runs.
It consists of DevSound foraudio and DevVideo for video and includes:• interfaces for finding, loading and configuring codecs28MULTIMEDIA ARCHITECTURE• functionality for encoding, decoding, pre-processing and postprocessing audio and video• an audio policy that resolves the access priority for simultaneousclient requests to use the sound device (for example, to determinewhat happens if the phone rings while we are playing music); theaudio policy is often customized by the device manufacturer for eachhardware platform, so it may behave differently on different devices• a hardware device API that interfaces the low-level hardware devicesincluding optional hardware-accelerated codecs residing on a DSP orother dedicated hardware.The MDF contains codecs in the form of hardware device plug-ins;they are mainly provided by the device manufacturers to make use ofthe specific hardware present on the phone.
Despite the name, hardwaredevice plug-ins may be implemented entirely in software when no suitablehardware is available. You can read more about DevVideo and DevSoundin Chapters 4 and 5, respectively. Details of the hardware device plug-insand implementation of the adaptation layer are beyond the scope of thisbook, because they are the domain of device manufacturers only.2.4.3 Image Conversion Library (ICL)The image conversion library (ICL) provides support for still image decoding, encoding, scaling and rotation.
It provides facilities to convert singleand multiframe images stored in files or descriptors to CFbsBitmapobjects. The library also provides facilities to convert single-frame imagesfrom CFbsBitmap objects to files or descriptors in a number of formats.The ICL is a library based on ECOM plug-ins. It allows third partiesand phone manufacturers to add plug-ins to support more formats or totake advantage of hardware-accelerated codecs available on the device.Symbian provides a comprehensive set of ICL plug-ins to facilitatesome of the more common image formats, such as JPEG, GIF, BMP,WBMP, TIFF, PNG, WMF, Windows icons and over-the-air bitmaps.Device manufacturers may choose to remove, replace or add to theSymbian supplied plug-ins but most are usually left as standard (seeChapter 6).Figure 2.5 shows the ICL architecture. The client application doesnot access the plug-in directly as all communication is done via theICL client APIs – the CImageDecoder, CBufferedImageDecoder,CImageEncoder and CImageTransform classes.The ICL framework provides a communication layer between the clientAPIs and the actual ICL plug-in, and all plug-in control is performed viathis layer.
The ICL framework can automatically load the relevant ICLMULTIMEDIA SUBSYSTEM29ClientapplicationDecoding/encoding clientAPIsICL frameworkPlug-in interfaceICL plug-inFigure 2.5 ICL architectureplug-in needed for the chosen image processing, identifying an image forthe purposes of plug-in assignment by its type (BMP, GIF, JPEG, etc).Chapter 6 gives a detailed explanation of the ICL and how it can beused. Client usage is discussed for common file formats, image encoding,image decoding, displaying images and transforming images.2.4.4 Onboard Camera API (ECam)The Onboard Camera API (ECam) is a common API that provides themeans to control any digital camera on a mobile phone and to requestand receive specific image data from it.It enables capturing of single or multiple frames and configuration ofthe camera’s settings, such as orientation, image format, capture size,zoom, exposure, white balance, etc.Symbian OS provides the onboard camera API definition to ensuresource compatibility.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
