3. Plug-in Architecture (插件的架构)

前面提到过MMF设计要考虑到为开发者提供灵活性，MMF插件的架构本身是个可配置的由几个可插入组件部分组成的框架。因此证件和第三方开发者能提供自己的控制类，格式，编解码和数据源和接收器以强化多媒体框架的能力。

MMF插件要求的必须组件是controller，它为client提供访问硬件或者其他可选插件的接口。简单的理解可以把插件架构分为如下几个部分：

1)  Plug-in controller，   插件控制

2)  Data path, data source, and data sink， 数据路径，数据源，数据接收器

3） Codec， 编解码

1） Plug-in Controller

       Plug-in controller是CMMFController接口的一个具体实现，它负责在一个或多个数据源之间控制数据流，把数据转换成不同的格式，然后他们传递给一个或者多个数据接收器。Plug-in controller包含在一个controller framework的proxy会话中，并且和一个proxy服务关联；每一个plug-in controller运行在应用进程中的一个独立的线程中。

       在图3中一个标准的音频plug-in controller 由CMMFAudioController类描述。Controller能被实现成一个单一完整的插件组件以管理数据转换，传输到低层的各个方面。

2）Data Source, Data Sink, Data Path

       数据源和接收器是输入输出设备的软件表现，例如文件，数据流，通信断口，扬声器，麦克风，摄像机以及显示。这些都是ECOM plug-in，用来支持MMFcontroller plug-in。他们由controller framework创建并拥有，他们的引用都通过AddDataSource()和AddDataSink()方法传递给controller plug-in，但是他们不被controller plug-in所拥有，因此他们的释放不应该由controller plug-in负责，而由客户应用调用RemoveDataSourceL()和RemoveDataSinkL()来删除对其的引用以及让controller framework负责删除部分特殊数据源和接收器对象。

       数据源和数据接收器由MDataSource和MDataSink两个微型类表示，他们只是数据提供者和数据消费者的抽象的概念。他们包含有方法通过检查各自的FourCC code来验证是否有数据传来或者传递的数据格式是否正确。（FourCC，the Four Character Code 是一个四字节的代码存储在文件头部，包含有多媒体数据的图像，声音或者视频信息。）

       以下是数据源和数据接收器的最小必须部分：CMMFFile， CMMFDescriptor， CMMFUrlSource， CMMFUrlSink， CMMFAudioInput， CMMFAudioOutput。

       为了更好的控制插件之间的数据传输，MMF提供了一个帮助类CMMFDataPath，该类派生自MDataSource和MDataSink。该类是个基础类，协调数据源和目标缓冲间的数据流动，必要时还使用编解码器。在插件设计时使用data path能消除controller处理数据的复杂性。

       每个data path对象在独立的线程中运行，能提高controller为多个数据源和接收器的服务性能。当源缓冲区中的数据在发送到接收器前需要格式化，CMMFDataPath使用两个格式化类CMMFFormatDecode或者CMMFFormatEncode来进行格式化处理。如果接收器需要与数据源不同的数据类型，那么data path需要使用软件编解码器（派生自CMMFCodec）来进行处理。

                      图 6   Class diagram for a common MMF audio plug-in

3） Format Objects

       格式化对象是ECOM plug-ins，能处理媒体源和接收器数据的格式，不需要controller帮助就能有效的抽取编码规范进行格式识别，并允许单个controller plug-in支持多种数据格式。使用格式化插件，controller plug-in能动态的扩展以支持更多的数据格式。

       格式化插件为data path的数据源和接收器担当解释器的职责。一种格式可能包含一种或者多种数据类型，例如WAV格式包含一系列不同的数据类型，如PCM，ADPCM，GSM6.10，DolbyAC-2， MPEG-1等。不像编解码器对于特定数据格式执行基于算法的数据压缩或者解压缩；格式化对象主要进行数据打包或者解包，分析并剥去文件头部，定位文件实际的播放位置，分离多路的音频或者视频流进行播放以及查找规范的媒体元数据属性，如频道数，比特流，采样率，帧大小等。

       有两种格式化对象，格式解码和格式编码。格式解码包含在CMMFFormatDecode类种，而格式编码则基于CMMFormatEncode类执行编码，比如录音。

       下图描述一个WAV文件播放的样式，CMMFFile代表WAV文件的数据源，CMMFAudioOutput对象抽象了到音频设备接收器的接口，CMMFDataPath在格式化类CMMFWavFormatRead对象的帮助下协调播放文件和底层音频接收器之间的数据流动。如果该WAV文件包含有封装过的压缩数据类型，比如MPEG-1，那么data path将加载CMMFCodec-based 类转换数据类型到能被音频硬件处理的数据类型，比如PCM16。

                     图 7 格式化对象和data path，source，sinks以及codecs之间的关系

4） Codecs

       解码器执行各种不同压缩数据类型间的转换，MMF主要的转换有两种：MMF软换编解码和硬件加速编解码（DSP-based）。

       软件的编解码器派生自CMMFCodec类，通过CMMFDataPath或者CMMFDataPathProxy进行数据转换。支持硬件加速的编解码器主要依赖CMMFHWDevice接口，而加载和管理硬件的编解码超出了controller的能力。

3．Sound Device

       Sound device提供MMF和音频硬件间的连接，其主要职责包括为应用提供可访问的音频资源，准备硬件播放就绪，选择不同的硬件加速编解码器，调节音量，帮助回放和记录。

       每个使用音频资源的应用都拥有一个CMMFDevSound的实例，并且关联着由RMMFAudioPolicyProxy对象管理的Audio policy规则。Audio policy组件决定CMMFDevSound的哪个实例应该被批准访问音频硬件。

       值得一提的是应用也可以不通过MMF直接访问DevSound，这主要是为了满足游戏或者类似的应用需要直接访问音频设备的特点。

4．Audio Policy

       该组件用来管理多个请求同时访问音频硬件的优先权问题。

5．Hardware Device API

       MMF到硬件部分的接口通过最外层hardware device API提供。这个接口被实现为ECOM plug-in并负责处理MMF和音频硬件之间的数据流。下图显示了底层MMF组件间以及和controller plug-in之间的相互关系。

                                                                      图 8

6．Other Multimedia APIs

       在多媒体应用种除了MMF框架外，还有一些通用的服务和库供使用，这些服务包括font和bitmap服务以及窗口服务。字体和位图服务处理内存种的字体和位图而窗口服务处理应用的资源输入输出，例如屏幕，指针，键区等。另外还有一个图像转换库ICL，专门用来把

图像转换到symbian OS能识别的格式；以及一个位图转换库提供图像旋转和缩放等。

       1） Font and Bitmap Server

              Font和bitmap处理文本和位图在屏幕上的显示，也提供创建和管理离屏位图（即双缓存），离屏位图创建时结合使用CfbsbitmapDevice， CfbsbitGc和CfbsBitmap类。

              下图是该服务种Graphics Device和Graphics context的类层次图：

                                                        图 9  graphics device classes

       2 )  Window Server

              窗口服务使应用能和设备的屏幕进行交换。因此任何由用户接口的应用都需要使用window 服务。该服务决定哪个应用接收输入以及能访问设备屏幕。一个window对象代表一个屏幕区，应用能用Rwindow类对其重画，该类是一个标准窗口类，派生于抽象基类RdrawableWindow。一个应用通过RwsSession连接window服务，通过连接后，应用能访问显示和接收与显示相关的事件。下图是window server和应用间的控制流图。

                                          图 10 windows server和应用间的控制流

3 ) Bitmap Transform Library

                                                 图 11

4 )  Image Conversion Library

                                                        图 12