W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Systematic access to media/plugin metadata

From: Danny Ayers <danny.ayers@gmail.com>
Date: Wed, 13 Apr 2011 15:31:14 +0200
Message-ID: <BANLkTikKMg1J7w9u8L4JQTxQh-pBYOKGSw@mail.gmail.com>
To: Philip J├Ągenstedt <philipj@opera.com>
Cc: public-html@w3.org
On 13 April 2011 14:15, Philip J├Ągenstedt <philipj@opera.com> wrote:

> 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.)

Right, I hadn't had quite enough coffee...

> 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)

Yep, absolutely. I find it odd we don't have a consistent API for
accessing such data.

> I agree with Henri that the server is well suited to extracting data like
> this.

Sure, but why shouldn't client-side extraction it be an option for the

An open-ended name-value kind of API for exposing arbitrary metadata
> immediately falls back to having to standardize the names and values.

But the HTML5 group doesn't have to standardize them. It's fairly easy
to imagine specifications in line with RDF that rely on URI-named
properties, likewise folksonomy-style ad hoc conventions are possible.

> 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.

That spec does have it's good points, but I personally think a much
simpler API would get more use.


Received on Wednesday, 13 April 2011 13:31:42 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:36 UTC