Re: OMA Standard Transcoding Interface and Content Transformation

 From what you are saying, Francois, we'd consider this server side 
adaptation, in that it is in the control of the content provider, and 
hence out of scope of what we are talking about?

Jo

On 06/11/2008 10:58, Francois Daoust wrote:
> 
> Hi,
> 
> LC-2051 mentions the work of the OMA on a Standard Transcoding Interface 
> (STI) and recommends we take a look at it:
> 
> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2051 
> 
> 
> 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:
>  http://www.openmobilealliance.org/Technical/release_program/sti_v10.aspx
> 
> 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 
> specification:
> 
> http://forge.morfeo-project.org/wiki_en/index.php/Transcoding_Module_Evolution#Implementations 
> 
> 
> 
> 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.
> 
> 
> Francois.
> 
>

Received on Thursday, 6 November 2008 13:14:31 UTC