Last update: 2011/08/21
MPEG is about formats but can also be about products and services handling them
In its quest to provide the necessary standard for the Digital Media industry MPEG started the MPEG Multimedia Middleware (M3W), a complete set of standards defining technologies required in a multimedia device. When responses to the M3W CfP were received MPEG selected the proposal coming from the Universal Home API (UHAPI) consortium that had developed a pretty complete solution.
M3W is ISO/IEC 23004 and nicknamed MPEG-E. It is organised in eight parts
Part 1 “Architecture” describes the M3W architecture and APIs. In M3W there are 3 distinct layers:
Fig. 1 - The software structure of an M3W system.
The scope of M3W is limited to the specification of the M3W API and realisation technology. In Fig. 1, this means the L-shaped yellow part and its interfaces depicted by the green line.
Part 2 “Multimedia API” specifies access to the functionalities provided by conforming multimedia platforms such as Media Processing Services (including coding, decoding and trans-coding), Media Delivery Services (through files, streams, messages), Digital Rights Management (DRM) Services, Access to data (e.g. media content) and Access to, Edit and Search Metadata.
Part 3 “Component Model” specifies a technology enabling cost effective software development and an increase in productivity through software reuse and easy software integration.
Part 4 “Resource and Quality Management” specifies a framework for resource management aiming to optimise and guarantee the Quality of Service that is delivered to the end-user in a situation where resources are constrained.
Part 5 “Component Download” specifies a download framework enabling controlled download of software components to a device.
Part 6 “Fault Management” specifies a framework for fault management with the goal to have a dependable/reliable system in the context of faults. These can be introduced due to upgrades and extensions out of the control of the device vendor, or because it is impossible to test all traces and configurations in today’s complex software systems.
Part 7 “System Integrity Management” specifies a framework for integrity management with the goal to have controlled upgrading and extension, in the sense that there is a reduced chance of breaking the system during an upgrade/extension or to provide the ability to restore a consistent configuration.
Part 8 “Reference Software and Conformance” is the usual complement as with the other MPEG standards.
Part 2 of M3W does not define a multimedia API but how one can be called. The ISO/IEX 23006 Multimedia Service Platform Technologies standard nicknamed MPEG-M includes Part 2 MPEG Extensible Middleware (MXM) that provides the MPEG solution for it. MXM is a collection of MPEG standards made accessible through standard APIs to Applications. The technologies themselves are implemented as "Engines". Engines are of two types: Protocol Engines (PE) derived from Part 4 and Technology Engines (TE) derived from other MPEG standards. Application typically needs “chains” of engines, MXM also provides examples of Orchestrator Engines that are capable of creating chains of Engines that can execute a high-level application call such as “Play”.
Fig. 2 – The MXM standard
MPEG-M also includes Part 4 Elementary Services. This part has been motivated by the fact that many digital media related services are actually a combination of elementary services that are variously recombined. MPEG has seen that with the standardisation of a set of technology elements and communication protocols, it will be possible to facilitate the creation of aggregated services, even on demand, starting from a set of standard elementary services.
The examples depicted in Fig. 3 explains how Elementary Services can be aggregated to provide full-fledged services. Assuming that there is a Service Provider (SP) for each Elementary Service, a User may ask the Post Content SP to get a sequence of songs satisfying certain Content and User Descriptions. Fig. 3depicts how a chain of Services can be set up to respond to the User’s request.
Fig. 3 – A possible services chain centred around Post Content SP
End User would contact Post Content SP who would get appropriate information from Describe Content SP and Describe User SP to prepare the sequence of songs using its internal logic. He would then get the necessary licences from Create Licence SP. The sequence (“titles”) of songs would then be handed over to Package Content SP. Package Content SP will get the songs (“Resources”) from Store Content SP and hand over the Packaged Content to Deliver Content SP who will stream the Packaged Content to End User.
MPEG-M Part 4 specifies a set of standard Elementary Services and related protocols to enable distributed applications to exchange information about entities playing a role in digital media services (end users and service providers), e.g. Content, Contract, Device, Event and User, and the processing that a party may wish to execute on those entities, such as Authenticate, Create, Deliver, Describe, Identify, Negotiate, Process, Request, Search and Transact.
It is clear that in the real world Service Providers would not be able to exploit the potential of the standard if they were confined to only offer “Elementary Services”. Therefore MPEG-M part 5 provides the additional standard technology that allows the standard combination of Elementary Services to create Aggregated Services. In the Fig. 3 example Post Content SP may wish to bundle, for example, the roles of Describe User and Package Content.
