symba (Symbian Books), страница 9

DRM systems are very important to theentertainment industry for secure information distribution, as they allowcontent owners to specify and control the usage policy for their content.For example, DRM prevents one person from buying a music album andthen giving away or selling the music.Device manufacturers have historically implemented their own supportfor proprietary or industry-standard DRM solutions (e.g. OMA DRM v1.0).This made life difficult for application developers, who were either unableto access certain content or had to use different methods to do so ondifferent platforms. Fortunately, from Symbian OS v9.1 onwards DRMprotected audio and video content are supported via the Content AccessFramework (CAF).

The Content Access Framework provides a commoninterface for applications to access content regardless of whether thecontent is protected or not. The landscape of DRM changes constantlyand any particular Symbian smartphone can implement different DRMschemes.3 CAF allows the media player to be oblivious to the particularprotection scheme by providing a common API layer.Internally, the CAF behaves as a switch between different agents,known as Content Access Agents. Each agent is an ECOM plug-in thatimplements one or more DRM schemes. CAF determines the corresponding agent dynamically for each file.Symbian OS also provides a default agent for reading unprotected files.This way, media players can use the same APIs without detecting DRMpresence at run time.Since CAF agents are responsible for proper enforcement of the DRMscheme, they are likely to be separated into a client and a server,where the server ensures integrity of access rights.

In this way, onlythe server process needs to be trusted with the DRM capability, while theclient process never has direct access to unencrypted content. Due to thepossible client–server split, if the media file is stored in the player’s privatedata cage, it should be passed to the CAF by file handle; otherwise theagent’s server might not be able to open the file. Figure 2.2 summarizesthe top-level CAF architecture.3 At the time of writing, the most widespread DRM schemes supported by Symbiansmartphones are OMA DRM v1, OMA DRM v2.0/2.1 and WMDRM.22MULTIMEDIA ARCHITECTUREApplicationsCAFCAgentFactoryECOM plug-ininterfaceF32 AgentECOM plug-inDLLOMA AgentClient-sideECOM plug-inDLLProcess 2OMA AgentServer-sideDLLMPEG21 AgentClient-sideECOM plug-inDLLProcess 1Process 3MPEG21 AgentServer-sideDLLFigure 2.2 The Symbian OS CAF ArchitectureHaving presented the general framework for DRM support in SymbianOS, we move on to interfaces specific to multimedia content.

Theabstract class TMMSource4 provides a lightweight encapsulation of aDRM-protected content source. The audio and video clip playback APIsuse TMMSource as an argument in their Open() file methods. There aretwo subclasses of TMMSource that are commonly used:• TMMFileHandleSource allows a file handle to be provided.• TMMFileSource allows a file to be provided by name.DRM schemes (e.g. OMA DRM v2.0) may allow several media tracksto be embedded in a single archive file. In this case, the particular contentID can be supplied to these classes in order to choose the track to bedecoded.To enforce the protection of the content, the agent must know whatthe client intends to do with the content once it has been supplied withthe decoded version of that content.The TMMSource class and its subclasses allow the developer of amultimedia player to provide a DRM access intent (play, execute, pause,etc.), that indicates what the software intends to do with the data.

Thisaffects whether or not it is granted access to the content.4TMMSource is defined in mm\mmcaf.h and to use it you need to link against mmcommon.lib. More information about this class can be found in the Symbian DeveloperLibrary documentation.MULTIMEDIA SUBSYSTEM23DRM schemes may also adjust user’s consumption rights.

For example,an audio file may have a play count that allows the user to listen to thetrack a limited number of times. The intent needs to be carefully chosenby the audio player, so that rights are executed exactly when necessary.In order to access DRM-protected content encapsulated by one of theTMMSource subclasses, your process must have the DRM capability (adevice manufacturer capability – see Section 2.2).For more information about DRM support in Symbian OS and theContent Access Framework, see the Symbian Developer Library and theSDK documentation.2.4 Multimedia SubsystemThe Symbian OS multimedia subsystem provides functionality for• audio recording and playback• video recording and playback• still image conversion• camera control• FM radio receiver support.While some of the features are provided by Symbian OS licensees andnot by Symbian, the multimedia subsystem provides the basic frameworksto support them.

Furthermore the multimedia subsystem provides crossplatform compatibility for client applications and hardware accelerationplug-in writers to reduce the cost of porting applications and codecsbetween different platforms.The multimedia subsystem is a modular subsystem, constructed fromdiscrete parts, each of which contributes to the whole. This enables ahigh degree of configurability across a wide range of target hardware.Figure 2.3 provides an overview of the different components that comprisethe multimedia subsystem.The four boxes at the top of the diagram represent multimedia applications.

These can be provided by the UI platform, by the device manufacturer or by a third-party developer. The boxes underneath them representthe components of the multimedia subsystem. The image conversionlibrary and the majority of its plug-ins are provided by Symbian OS.Device manufacturers may replace some of the plug-ins with their ownoptimized versions (see Chapter 6 for more details). Symbian providesthe multimedia framework and whilst it is possible for anyone to writeplug-ins for it, they are generally supplied by the device manufacturer.Now let’s take a closer look at each multimedia component.24MULTIMEDIA ARCHITECTURE“Still Image” ClientApplication(e.g. web browser,image viewer)ImageConversionLibrary(ICL)“Multimedia” ClientApplication(e.g.

videoplayer/recorder)OnboardCamera API(ECam)RadioMultimediaFramework(MMF)MediaDeviceFramework(MDF)VoIPTunerRTPSIPFigure 2.3 The multimedia ecosystem2.4.1 The Multimedia Framework (MMF)The multimedia framework (MMF) uses ECOM plug-ins to provide amultithreaded framework for handling audio and video playback andrecording. It allows phone manufacturers and third parties to add plug-insto extend the audio and video capabilities, for example adding supportfor new formats.The MMF consists of the following basic layers:• Client-side utility APIs provide applications with a simple interfaceto use functionality provided by plug-ins or for low-level audiostreaming.• The controller framework resolves selection and launching of plugins and also facilitates message passing between applications andplug-ins.• The controller plug-ins are responsible for managing the data processing while moving data from the source (a file or URL) to the sink (ordestination, hardware or a file).

This includes writing or parsing thefile format and, for video controllers, multiplexing or de-multiplexingthe audio and video streams from or to the codecs.The MMF is based on a client–server architecture, linking client-sideutility APIs with the server-side controller plug-in interfaces. Applicationsuse the client APIs to control the playback or recording of the media andthe underlying controller framework creates a new thread to process themedia data.MULTIMEDIA SUBSYSTEM25MiddlewareClientThird partyAdaptationCMMFClientUtilitiesAPICustom APIMMF controller implementationsMMFLicenseeCustom APICMDFClientUtilitiesCore OSSymbianSymbian APISPICustom APIDevSound ProxyDevSound ServerMDFCMDFDevVideoSPIsVideoimplementationProprietary APIHW device HAIAdaptationSymbian frameworkCustom APIPolicy APICustom APIHW device HAIsECAM HAIHardware adaptationEffectsCodecsPolicyRoutingResourcePre/post processorCameraThe implementation components and proprietary APIs shownare generic examples – different licensees handle the audioadaptation in different waysFigure 2.4MMF architectureHow the MMF worksTo have a better understanding of how it all works, see Figure 2.4.