W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > November 2008

OMA Standard Transcoding Interface and Content Transformation

From: Francois Daoust <fd@w3.org>
Date: Thu, 06 Nov 2008 11:58:41 +0100
Message-ID: <4912CDE1.7060100@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>


LC-2051 mentions the work of the OMA on a Standard Transcoding Interface 
(STI) and recommends we take a look at it:

I took ACTION-868 to review OMA STI. Here's my report.

In short
No overlap between OMA STI and the CT Guidelines (apart from the fact 
that they're both talking about transcoding, that is).
The only possible change we may do is to add a reference to the OMA STI 
in the Scope for Future Work along with POWDER.

Version of OMA STI
I tried to download the latest version of the specifications, but the 
links on the following page are broken:

If anyone knows how to retrieve the latest version, I'm interested. I 
reviewed the 20050704 release. I don't know whether it is still 
accurate, but the overall objectives, requirements and spirit of the 
specifications surely haven't changed.

Description of OMA STI
As explained in the Last Call comment, the OMA STI specification is 
meant for an architecture where a Content Provider requests 
transformation to a third-party transcoding service. Transformation 
operations are typically intended to convert and adjust media content 
(audio, pictures, videos) between different formats so that they may be 
served to a large number of devices. OMA STI is thus a Web services 
interface whose typical work flow for Web browsing could be described 
with the following use case:
  1. a Content Provider receives a request from an end-user on some 
audio file.
  2. the Content Provider usually serves its audio files as Ogg Vorbis 
files. It detects that the end-user device does not support this format, 
and sends a request to some transcoding server to convert the audio file 
to the MP3 format.
  3. the transcoding server performs the conversion and returns the 
result to the Content Provider.
  4. the Content Provider returns the converted audio file to the end-user.

OMA STI provides ways for the Content Provider to send multiple 
transcoding requests (called jobs) at once. This can be useful when you 
want the result to fit within a given size limit: all images of a page 
could thus be sent to the transcoding service with a "please make sure 
the sum of the sizes of all the converted images does not exceed 50KB" 
directive for instance.

The MORFEO project web site describes a few implementations of the 

Relationship with the CT Guidelines
There is no direct overlap between OMA STI and the Content 
Transformation Guidelines.
The guidelines cover the case where the transcoding platform is not a 
third-party entity but a non-transparent proxy that intercepts all HTTP 
messages between the Content Provider and the end-user.

As such, there is not much we can extract from the interface specification.

I can't think of any incompatibility between OMA STI and the CT 
guidelines either. In other words, for the purpose of the CT guidelines, 
a Content Provider that makes use of a third-party transcoding service 
is still a Content Provider.

One thing that may be noted is that OMA STI defines a kind of vocabulary 
to describe transformation operations, and it could be integrated in a 
potential future work on the vocabulary we envision and that could be 
used in POWDER. Mentioning OMA STI in the Scope for Future Work appendix 
along with POWDER might be a good idea.

Received on Thursday, 6 November 2008 10:59:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC