Views

TOOLBOX

LANGUAGES

Transcoding Module Evolution

From Morfeo Wiki

Jump to: navigation, search

Contents

Current approach

Introduction

Current state of MyMobileWeb transcoder module allows dynamic adaptation of images, including image resizing respect device’s display size and image conversion to fit the format needed by target terminal.

To carry out this issue MyMobileWeb uses the following libraries:

  • size transformations: JAI
  • format transformations: WBMPMaster, Gif89Encoder, Batik.
  • weight transformations: JAI

Architecture

The current architecture is compound of five packages which are shown below. Each package links to the corresponding class diagram.


CSS properties

MyMobileWeb users can guide the transcoding process by means of the CSS properties listing below:

  • Transcode: boolean variable that stays whether transcoding should be applied to specified image or not.
  • Weight-width: weight of the width of the image respect display's width
  • Weight-height: weight of the height of the image respect display's height
  • Aspect-ratio: maintaining aspect ratio, yes or no?
  • Width: width of the image
  • Height: height of the image

OMA STI

The Open Mobile Alliance (OMA) has defined a Standard Transcoding Interface (STI v1.0) between the application servers and the media adaptation engine in order to enable a new architecture where the transcoding engine is shared between various services deployed at the operator's site. The use of STI in the transcoding module evolution will be considered since MyMobileWeb has a commitment with open standards, so it is reasonable to follow the approach of the greatest organization in the world standardizing the mobile technologies.

Architecture

The scope of the OMA Standard Transcoding Interface (STI) sub-working group is to provide a standardized interface between Multimedia Application Platforms and a Transcoding Platform to allow transcoding of media Content files based on Application specified transcoding parameters and/or User Equipment capabilities. In spite of the fact that the STI goal is to be generic enough to allow different applications (such as browsing, media download services, push services, etc) to make use of such an interface, those aspects closer to MyMobileWeb platform use case will be considered with special attention in this chapter. The Standard Transcoding Interface defines three reference points:

  • TI-1: Transcoding interface
  • TI-2 and TI-3: Access to remote content stored in databases or servers
  • TI-4 and TI-5: Access to reference databases or servers


The picture below shows a generic view of the OMA generic architecture (grey arrows are out of the scope of STI), including the possible transference protocols. Particularly, the access to a Device Description Repository (the entity described as “UAProf DB or Server”) is being taken into account by the MyMobileWeb project through its participation in the W3C Device Description working group, as partners of this project are editors of the document Device Description Repository API, which is going to be proposed as a W3C Recommendation.

STI Architecture
STI Architecture

Taking into account this general view of what STI offers, it's possible to go further and analyse the MyMobileWeb use case:

  • MyMobileWeb Application would represent the “Application Platform” in the picture.
  • The Transcoding Platform would be the combination of hardware and software that provide transcoding functionality.
  • The Application Platform and the Transcoding Platform can share the same physical machine, but are still different logical entities using STI as the interface.

Other interesting issues are commented below:

  • The Application Platform may include the output formats and characteristics (i.e. the detailed transcoding parameters) in the transcoding request and/or include a reference to User Equipment information (e.g. handset profile reference). The Transcoding Platform may use the handset profile reference to retrieve the detailed transcoding profile from the reference database/server or from an internal database, and/or retrieve the basic User Equipment capabilities from a UAProf database/server (or, in general, a Device Description Repository).
  • The resulting User Equipment capabilities and/or transcoding parameters are then used by the Transcoding Platform to perform the content adaptation that is best suited for the specific User Equipment and the Application requirements.
  • In the response, in addition to the transcoded content, the Transcoding Platform will return information such as a return code, total duration (for transcoding), and file size. How the Application Platform uses this additional information (if at all) is out of the scope of the STI specification.
  • The Transcoding Platform is also responsible for reporting (or returning) errors and warnings to the requesting Application Platform. The errors can be attributed to an erroneous transcoding request or the inability for the Transcoding Platform to perform the requested transcoding.

How to perform a TranscodingRequest

The next picture shows the overall UML Diagram to compose a transcoding Request following STI standard.

STI overall UML diagram
STI overall UML diagram

The figure below represents a detailed transcodingParams UML Diagram, very useful to see how to specify the transoding parameters:

STI Transcoding Params UML Diagram
STI Transcoding Params UML Diagram

Implementations

Alembik (http://alembik.sourceforge.net/)

Alembik Media Transcoding Server is a Java application providing transcoding services for variety of clients. Sharing the name with a device for carrying out alchemical transmutations it reshapes and reformats media files according to needs and capabilities of any environment. Any Alembik client needs only to pass to the server the URL of a media file with a set of transcoding parameters (like desired dimensions, size, mime-type, etc.). The latters may even remain unspecified - Alembik will evaluate them automatically according to the User-Agent string passed by a client.

Alembik is developed as an open-source project, whose goal is to provide an OMA-STI fully-compliant media transcoding server based on J2EE technology. OMA-STI stands for Open Mobile Alliance's Standard Transcoding Interface, which precisely defines a contract between a client (requesting some media files to be transcoded) and a server (which carries out the transformation process according to the passed parameters set). Alembik is the first open-source attempt to meet that standard.

There are four communication channels at present that Alembik server exposes:

  • SOAP service for all types of clients,
  • JSP tag library for development in Java-based web containers,
  • EJB facade for J2EE clients,
  • HTTP service for web pages development in any environment.

The application architecture is composed in a modular fashion, where five main modules are: Java transcoding API, SOAP service implementation, EJB-based facade (including JMS-based asynchronous processing support), JSP tag library and core libraries. Further on the core part may be logically divided into several blocks:

  • Pluggable media processors, each one serving a particular media type (image, audio or video),
  • Storage providing media loading features and quick access cache for original and transcoded media files,
  • WURFL library-based User-Agent resolver,
  • Mime-type detector using media's file extension and actual content analysis (Mime-Util library),
  • Pre-defined transcoding profiles repository,
  • Synchronizer component securing concurrent access to resources.

Alembik may be deployed into any Java-based web/application server, although it has been so far tested and released for three platforms only: Glassfish, JBoss and Apache-Tomcat. Each release bundle contains a relevant archive file (EAR or WAR) as well as client JAR files (both SOAP- and EJB-based) and an example web application (WAR) showing the JSP transcoding tag library in action. Although still in the beta stage, Alembik has been already deployed in production for Spanish telecom operators (e.g. Telefonica and Vodafone).


Gaia Transcoder Server (http://gaia-git.sourceforge.net/roadmap.htm)

Gaia Reply has announced, as the second step of their roadmap, the implementation of a Transcoder Server (TS) compliant with OMA STI standard, supporting transcoding for image, video and audio too. The server will response to SOAP-RPC calls. As far as transcoding server architecture is concerned they have announced their intention to implement the following components:

  • a STI compliant API interface for managing images, audio or video
  • a STI parser to enable STI messages based RPC

The transcoding process will be characterized by four different steps:

  • the transcoding server receives an STI request
  • the parser interprets the message and translate it into a sequence of API interface calls
  • the API interface implementation calls "plugged" transcoding library native methods
  • the plugged transcoding library (audio,image or video) performs transcoding stuff

Volantis (http://opensource.volantis.com/)

On the 19th of March Volantis has released its Mobility Server to the open source community under the GNU General Public License (GPL), version three. As they had announced in the overview (http://www.volantis.com/docs/Volantis-Mobility-Server-1.0-Overview.pdf) they offer STI support, but it basically consists on mapping the ResourceDescriptor they use to describe a transcoding operation into a TranscodingRequest with an unique TranscodingJob (according to OMA interfaces) in order to make easy for the user to invoke an external STI transcoding server. However they haven`t released any STI-compliant transcoder.


New MyMobileWeb transcoding module

The intention is to improve the functionality of the current transcoder by designing a new module which:

  • covers different content types (audio, video, etc) and formats.
  • has to be open enough to make easy the incorporation of new features.
  • complies the existing standards regarding transcoding for mobile devices.

In order to follow, as far as possible, the OMA Standard Transcoding Interface, MyMobileWeb will provide a generic STITranscoder interface which has to be implemented in order to invoke a possible remote transcoding server. The main method of this interface is called transcode and it receives a TranscodingRequest, compound internally by MyMobileWeb, and it returns a TranscodingResponse, made up by the Transcoding Server.

By default MyMobileWeb will include two implementations of such a interface:

  • LocalSTITranscoder: in order to invoke Alembik libraries locally
  • RemoteSTITranscoder: in order to invoke a generic fully-compliant STI service using SOAP

By means of configuration properties users could choose between both possibilities.

CSS Properties

A first approach for the transcoding module CSS properties has been designed based on the STI specification, so users could define most of the transformations specified in STI, by means of CSS.

A basic CSS properties definition could be specified as follows: 

link.image.transcode {
        brightness-level:15;
	codec:image/jpeg;
	codec-params: mode lossless quality-factor 90;
	color-level: 15;
	color-scheme-depth: 10;
	color-scheme-scheme:paletteColor;
	content-type:image/jpeg;
	content-type-params: type-jfif;
	contrast-level:10;
        height:80%;
	level-correction:true;
	mirror-axis:UD;
	noise-reduction:false;
	resize-directive:aspectRatio;
	rotation:180;
	sharpen:false;
	size-limit:454900;
	transcode:true;
	upsize-allowed:false;
	width:80%;    
}
Retrieved from "http://forge.morfeo-project.org/wiki_en/index.php/Transcoding_Module_Evolution"