Re: Systematic access to media/plugin metadata

On Wed, 13 Apr 2011 13:19:52 +0200, Danny Ayers <danny.ayers@gmail.com>  
wrote:

> On 13 April 2011 12:49, Henri Sivonen <hsivonen@iki.fi> wrote:

>> The server is a notable part of a Web app. I don't think it is a useful
>> goal to seek to move everything to the browser side.
>
> I agree, but given that typically the image/media object will be
> transferred to the client for rendering, it seems reasonable to be
> able to access any embedded metadata there too.
>
> For popular formats it is commonplace to have other aspects of the
> data handling delegated to the client, e.g. PDFs are served as-is and
> the browser will take care of things like pagination within the PDF.
> You don't often see the pages of a PDF split and converted
> server-side. Why should the metadata be treated as a special case?

Things like that are necessary for rendering the document at all. A more  
reasonable comparison would be exposing the TOC and other embedded  
metadata to scripts. (Nitpick: browsers generally don't support PDF as  
such, it's handled by plugins.)

There are many things about media resources that the UA knows but does not  
expose to scripts, which could be considered metadata. Examples:

* the size in bytes of the resource
* the type of the resource: JPEG/PNG/Ogg/WebM/WAVE/etc
* the sample format and sample rate of audio tracks
* the pixel format and color space of video tracks
* the frame rate of video tracks (if it is known to be constant)

I agree with Henri that the server is well suited to extracting data like  
this. An open-ended name-value kind of API for exposing arbitrary metadata  
immediately falls back to having to standardize the names and values.  
Something like <http://www.w3.org/TR/mediaont-api-1.0/> might be a better  
approach, even though I don't think that API is suitable for  
implementation in browsers as-is.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 13 April 2011 12:16:05 UTC