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

My answer was a bit short ;-)

You got two sets of negative motivated feedback. I don't think you can suggest to remove it any longer.  In any case, one doesn't prevent the other.

And by all means, if you want to use extended MIME types to express this maybe would it be better to call the property MimeType of RFC4281_MimeType to make parsers aware more than by using 'format', which we know as always been a source of trouble since the early Dublin Core days.

Regards,

Jean-Pierre 

-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Evain, Jean-Pierre
Sent: mardi, 7. décembre 2010 13:04
To: 'Joakim Söderberg'; Bailer, Werner; public-media-annotation@w3.org
Subject: RE: Definition for ma:compressions and ma:format (Action 368)

NO

-----Original Message-----
From: Joakim Söderberg [mailto:joakim.soderberg@ericsson.com] 
Sent: mardi, 7. décembre 2010 11:49
To: Evain, Jean-Pierre; Bailer, Werner; public-media-annotation@w3.org
Subject: RE: Definition for ma:compressions and ma:format (Action 368)

So how about remove "ma:compression" and have only "ma:format" with a profile parameter like David suggests, if that isn't patented:-)?

Or do you have any other suggestions?

/Joakim
-----Original Message-----
From: Evain, Jean-Pierre [mailto:evain@ebu.ch] 
Sent: den 5 december 2010 13:50
To: Joakim Söderberg; Bailer, Werner; public-media-annotation@w3.org
Subject: RE : Definition for ma:compressions and ma:format (Action 368)

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

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

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

-----------------------------------------
**************************************************
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, 7 December 2010 12:20:19 UTC