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

Received on Sunday, 5 December 2010 10:20:45 UTC