RE: Recapitulation of ma:format vs. ma:compression.

And extended MIME type don't solve this issue either.

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: mardi, 18. janvier 2011 15:43
To: Evain, Jean-Pierre
Cc: Joakim Söderberg; 'Bailer, Werner'; public-media-annotation@w3.org
Subject: Re: Recapitulation of ma:format vs. ma:compression.


On Jan 18, 2011, at 0:15 , Evain, Jean-Pierre wrote:

> All the names listed e.g. in the mpeg classification schemes of audio and video codecs are of course eligible for use in compression.

I don't think that answers the question.  I repeat, what is the namespace?  Who defines the names?  Where is the registry?

The identifier used for H.264 in mpeg-2 transport is quite different from the one used in MP4, and quite different from the one used in ASF.  Which one do you use, or something else?

This field is completely pointless if its contents are undefined, which is the current state, as far as I can tell.

> 
> 
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com] 
> Sent: mardi, 18. janvier 2011 00:41
> To: Joakim Söderberg
> Cc: Evain, Jean-Pierre; 'Bailer, Werner'; public-media-annotation@w3.org
> Subject: Re: Recapitulation of ma:format vs. ma:compression.
> 
> 
> On Jan 17, 2011, at 0:48 , Joakim Söderberg wrote:
> 
>> I'm sorry, I forgot that there was a vote about the name for "ma:compression" in April 2010. So to clarify, the present suggestion is:
>> format 
>> compression
>> 
>> We should add "recommend practice of RFC4281 whenever possible" to description text for "format", and explain that ma:compression, can be used to describe the encoding of a track rather than a complete file.
>> 
> 
> I still don't understand what the names of compression formats are.  I am unaware of a uniform namespace.
> 
> Can you tell me what I would put in there, if format is left empty, if I want to express:
> 
> * Cinepak video
> * Theora video
> * IMA 4:1 audio
> * uLaw audio
> * Intel Indeo Video
> 
> ?
> 
> 
> 
> 
>> Ok?
>> 
>> /Joakim
>> 
>> -----Original Message-----
>> From: Evain, Jean-Pierre [mailto:evain@ebu.ch] 
>> Sent: den 17 januari 2011 09:13
>> To: 'Bailer, Werner'; Joakim Söderberg
>> Cc: public-media-annotation@w3.org
>> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>> 
>> Dear all,
>> 
>> I second the position of Werner to keep ma:compression for the same reasons.
>> 
>> Additionally, I have a problem with the methodology used. This is now a very old subject. Several changes to the ontology have been discussed two telcos ago (and I'll come back in another mail about things agreed and not implemented yet).  The use of MIME types had been discussed before the time of this call and the issue wasn't raised. And here it comes again.
>> 
>> The way the issue is (re-re-re-) presented is also weird. Why say we are back to where we started? There was a proposal. There was motivated disagreement. Hence, no consensus, no change.
>> 
>> End of the story.
>> 
>> Regards,
>> 
>> Jean-Pierre
>> 
>> -----Original Message-----
>> From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Bailer, Werner
>> Sent: lundi, 17. janvier 2011 08:49
>> To: Joakim Söderberg
>> Cc: public-media-annotation@w3.org
>> Subject: RE: Recapitulation of ma:format vs. ma:compression.
>> 
>> Dear Joakim, all,
>> 
>> Thanks for the summary, I'd like to add two points here:
>> - We should recommend the use of RFC4281 whenever possible, but we cannot rely that they exist for a particular format.
>> - There is a second reason to keep ma:compression (or codec), which is to describe the encoding of a track rather than a complete file.
>> 
>> Best regards,
>> Werner
>> 
>>> -----Original Message-----
>>> From: public-media-annotation-request@w3.org [mailto:public-media-
>>> annotation-request@w3.org] On Behalf Of Joakim Söderberg
>>> Sent: Montag, 17. Jänner 2011 08:36
>>> To: public-media-annotation@w3.org
>>> Subject: Recapitulation of ma:format vs. ma:compression.
>>> 
>>> Hello,
>>> 
>>> Some advice on the mailing list suggested that the rfc4281 mime-type
>>> extensions should be in ma:format, and to delete ma:compression or use
>>> it for the case there are no codec parameters, and rename it to
>>> "ma:codecs".
>>> 
>>> However, the group consensus was that it's not a way forward, since
>>> extended mime-types are not widely in use. So I would say we are back
>>> where we started; with ma:format and ma:compression. Unless we want to
>>> rename ma:compression to ma:codec?
>>> 
>>> /Joakim
>> 
>> 
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 

David Singer
Multimedia and Software Standards, Apple Inc.

-----------------------------------------
**************************************************
This email and any files transmitted with it 
are confidential and intended solely for the 
use of the individual or entity to whom they
are addressed. 
If you have received this email in error, 
please notify the system manager.
This footnote also confirms that this email 
message has been swept by the mailgateway
**************************************************

Received on Tuesday, 18 January 2011 14:50:27 UTC