W3C home > Mailing lists > Public > public-media-annotation@w3.org > November 2010

Re: Definition for ma:compressions and ma:format

From: David Singer <singer@apple.com>
Date: Mon, 29 Nov 2010 11:31:57 -0800
Cc: "Evain, Jean-Pierre" <evain@ebu.ch>, Joakim Söderberg <joakim.soderberg@ericsson.com>, "public-media-annotation@w3.org" <public-media-annotation@w3.org>, Robin Berjon <robin@berjon.com>, Torbjörn Einarsson <torbjorn.einarsson@ericsson.com>
Message-Id: <86F307C1-CF49-4949-9156-FA655BB60E94@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
I agree, it's not heavily used now.  I think it's more likely to get used in hand-written spaces (e.g. in a web page) than in automatic spaces (e.g. in HTTP content headers) simply because I don't expect web servers to do the kind of inspection needed to make these parameters automatically.

I think making it part of the format makes sense.  In fact, I am planning an update to this to add a "profiles" parameter, as well, and make it clearer what files these apply to (anything in the MP4 family, and QuickTime).  Review is welcome, let me know if you'd like to see it before I send off the I-D.

Given that there would then be two parameters, having an extended mime type makes even more sense.

(The profiles parameter would list the file-format 'compatible brands', which basically declares what specs the file adheres to, so it's both more general and more wide-ranging than just codecs, as a spec. may restrict more than just the codecs used).

On Nov 29, 2010, at 11:25 , Silvia Pfeiffer wrote:

> The codecs parameter of the MIME types has not been used extensively
> other than by MPEG FAIK. Ogg recently added it to their MIME type
> definition. WebM doesn't need it because it has restricted its codecs
> to VP8 and Vorbis. However, it is relatively simple to add the codecs
> parameter to the end of existing MIME types even if they are not
> standardized.
> 
> I would prefer using the codecs parameter on the MIME type in
> ma:format (why not call it ma:mimetype?). I also agree that
> ma:compression is obsolete then and should be removed.
> 
> Incidentally, HTML5 also uses MIME types with codecs parameter for this purpose.
> 
> Cheers,
> Silvia.
> 
> 2010/11/30 Evain, Jean-Pierre <evain@ebu.ch>:
>> It's a long time since I went to see the list of registered MIME types. I wonder where this is going with e.g. several video or mp4 Mime types (generic and vendor specific).
>> 
>> And I it looks like if it's just the beginning. Even some authors propose different types with the name under different vendors spaces ?!?!?!
>> 
>> Any views?
>> 
>> Jean-Pierre
>> 
>> -----Original Message-----
>> From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Joakim Söderberg
>> Sent: lundi, 29. novembre 2010 11:48
>> To: public-media-annotation@w3.org
>> Cc: Robin Berjon; Torbjörn Einarsson; David Singer
>> Subject: Definition for ma:compressions and ma:format
>> 
>> Regarding the definition for ma:compressions and ma:format.
>> 
>> The response I got from my colleague, Torbjörn Einarsson, is that he agrees with LC comment (LC-2418, Robin Berjon), in that's unclear what to return for "ma:compression" as it is defined now.
>> 
>> "- even something as simple as JPEG can be coded in different ways. The file format was called "jfif", but as we know "jpeg" became de facto."
>> 
>> He suggest that the mime-type (which is well defined) should be in ma:format (as it is) but also include rfc4281 extensions (that describes what's in the file).
>> Then consequently ma:compression becomes somewhat obsolete, but it could be used in for the case there are no codec parameters, and then perhaps rename it to "ma:codecs".
>> 
>> 
>> /Joakim
>> 
>> substantial: It's unclear what to return for Compression. Is JPEG a compression? Something more specific? Is it case sensitive? Partially controlled?
>> 
>> substantial: Does ma:format include media type parameters?
>> 
>> 
>> 
>> 
>> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Monday, 29 November 2010 19:32:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 29 November 2010 19:32:33 GMT