RE : RE : Definition for ma:compressions and ma:format (Action 368)

NO...

No, in fact there was aonother message starting by ...I guess I was to brief or something alomng these lines.



________________________________________
De : David Singer [singer@apple.com]
Date d'envoi : mercredi, 8. décembre 2010 02:13
Ā : Evain, Jean-Pierre
Cc : Joakim Söderberg; Bailer, Werner; public-media-annotation@w3.org
Objet : Re: RE : Definition for ma:compressions and ma:format (Action 368)

I assume this the detailed 'No' reply you meant...

On Dec 5, 2010, at 6:50 , Evain, Jean-Pierre wrote:

> Dear Joakim,
>
> I know you were answering to Werner but these are my comments:
>
> - your comments are based on the use of RFC4281 and I am not sure this is widely accepted/used from the comments received back when I asked the question.

But that's not relevant, as these are new, hand-coded, descriptions, aren't they (or at least, written by software aware of this spec.)

> - I think that pilling up all the codecs used one after the other idependently from the tracks is 1) stretching the use of RFC4281 2) highlighting a modelling eakness in the approach

It's what the RFC says do.  Rather importantly, separating the codecs from the format implies (falsely) that there is a global namespace for naming codecs;  there is not.  Having it part of the same parameter makes it clear that the codecs parameter is contextual on the container mime type.

It has the apparent downside that you cannot supply it for a container for which it's not defined, but this is the truth, since there is no global namespace for naming codecs.  It has to be defined to be usable in either a separate or the same attribute.

> - having MAWG globalising all track content description doesn't at all go in the direction of the multi-track discussion in the HTML group. Therefore, having a track by track description is relelvant to be compatible with what id being done in the multi-track HTML work, and if it is there then why not simply attach the codec to each track.

OK, indeed, putting it in the mime type loses which track has what.

>
> (over) Simplification doesn't have only virtues. You may want ot take it out from the MAWG ontology (and I hope we won't follow) but I'll certainly leave in e.g. EBUCore and promote it as a key distinctive feature towrads content providers.

What's the definition of the value space in EBUCore, i.e. how do you name codecs?

>
> Jean-Pierre
>
> ________________________________________
> De : public-media-annotation-request@w3.org [public-media-annotation-request@w3.org] de la part de Joakim Söderberg [joakim.soderberg@ericsson.com]
> Date d'envoi : dimanche, 5. décembre 2010 11:20
> Ā : Bailer, Werner; public-media-annotation@w3.org
> Objet : RE: Definition for ma:compressions and ma:format (Action 368)
>
> Dear Werner,
>
> In RFC4281, you may for the same file specify both the audio and video codecs, like in section 5 on examples:   Content-Type: video/3gpp; codecs="s263, samr" (s263 being video and samr being audio).
>
> The audio and video are in different tracks, but you may also have multiple audio and video tracks, and multiple video and audio (and subtitle) codecs. One can then simply add even more comma-separated codecs.
>
> As suggested by Torbjörn; it is not necessary to go into the details of the tracks including trackIDs, and whether there are any hint-tracks etc, but one should simply specify the codecs (and their parameters) being used. To handle detailed signaling whether the codecs are in separate tracks or in the same track is too detailed and hard to get right.
>
>
> /Joakim
>
> -----Original Message-----
> From: Bailer, Werner [mailto:werner.bailer@joanneum.at]
> Sent: den 30 november 2010 14:33
> To: Joakim Söderberg
> Subject: RE: Definition for ma:compressions and ma:format
>
> Yes of course it can be repeated for the different tracks, but IMO a MIME type is a bit strange there, i.e. for the raw stream.
>
> Werner
>
>> -----Original Message-----
>> From: Joakim Söderberg [mailto:joakim.soderberg@ericsson.com]
>> Sent: Dienstag, 30. November 2010 12:50
>> To: Bailer, Werner
>> Subject: RE: Definition for ma:compressions and ma:format
>>
>> Can't you repeat it for the different tracks?
>>
>> /Joakim
>>
>> -----Original Message-----
>> From: Bailer, Werner [mailto:werner.bailer@joanneum.at]
>> Sent: den 29 november 2010 11:59
>> To: Joakim Söderberg; public-media-annotation@w3.org
>> Cc: Robin Berjon; Torbjörn Einarsson; David Singer
>> Subject: RE: Definition for ma:compressions and ma:format
>>
>> Dear Joakim,
>>
>> The proposed approach works, if there is a single compressed stream
>> inside a file, i.e. the extended MIME type could be used to specify an
>> AVI file with MPEG-2 inside.
>>
>> However, in many cases, there are differently compressed streams
>> (typically video and one or more audio streams) in the container, in
>> which case ma:compression is needed for the track fragments.
>>
>> It seems that, when using extended MIME types (although I'm not sure if
>> they cover all cases), that ma:format is only needed for media
>> resources while ma:compression is only needed for tracks.
>>
>> 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, 29. November 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 Wednesday, 8 December 2010 15:14:41 UTC