Vorbis dev - Apr 2008 - Codec Parameter for Ogg media types

We interrupt your regularly scheduled program to bring you the following issue.

RFC3534bis is on hold.  I have addressed all feedback from Mr
Westerlund, except for the following:

From: Magnus Westerlund <magnus.westerlund[at]ericsson[dot]com>
Date: Fri, 11 Apr 2008 13:55:28 +0200
Subject: Re: Updated 3534bis (was Re: Request for review of Ogg Media
Types: video/ogg, audio/ogg, application/ogg)
To: Ivo Emanuel Gon?alves <justivo[at]gmail[dot]com>
>>> 2. Usage of RFC 4281 "codecs" parameter? It seems
reasonably to include
>>> these parameters. Any issues with adding the parameter? And if not,
how
>>> do you want to describe the content of the file format, what type
of
>>> identifier space for the different content?
>>
>> We also discussed this prior to writing the draft.  The conclusion was
>> that, while Ogg can encapsulate anything, most implementations expect
>> only Xiph own codecs, so the three media types specified for each type
>> of content is in theory enough to help implementations know what they
>> are dealing with.  That not to mention that Skeleton already informs
>> parsers of what is contained in Ogg, be the data served with or
>> without media types.
>>
>> We would like to avoid further complexity unless it is actually
necessary.
>
> I have to agree this is a difficult call. But there clearly are systems
> that would like to determine what to do with Ogg file without having to
> read the actual file. That include server side email filtering and
> transcoding. I would recommend that you actually introduce this as it
> helps in system where it is not desirable to download a file unless it
> actually is usable. An soon anyone starts including a new codec or
> content into ogg files the utility of this parameter grows. So I think
> it comes down to if you think if it has any potential to be a commonly
> used format where additional formats will desirable.
>
> I (personally) will not insist but I think it would be good.
We need to reach a consensus on this issue and, if possible, soon.  Comments?

RFC 4281, which describes codec parameters can be found here[1].

-Ivo

[1] http://www.rfc-editor.org/rfc/rfc4281.txt

Hi Ivo,

I am happy to add a codecs parameter to the mime types where they are
being used to identify a file's content, in particular over a network.

We would have e.g. a audio file example.oga with the mime type
audio/ogg; codecs=vorbis . Or a video example2.ogv with mime type
video/ogg; codecs="dirac, speex". It makes a lot of sense.

It is one of the things I was planning to add to the RFC anyway. The
codecs parameter is not necessary for all uses of mime types, but
where it is helpful, it should be introduced, since we have now also
introduced bucket types. This makes us more mainstream and alike to
the way other a/v mime types work, too.

Feel free to go ahead and add it to the RFC - if you need help, let me know.

Cheers,
Silvia.


On Mon, Apr 14, 2008 at 8:20 AM, Ivo Emanuel Gon?alves
<justivo at gmail.com> wrote:
> We interrupt your regularly scheduled program to bring you the following
issue.
>
>  RFC3534bis is on hold.  I have addressed all feedback from Mr
>  Westerlund, except for the following:
>
>  From: Magnus Westerlund <magnus.westerlund[at]ericsson[dot]com>
>  Date: Fri, 11 Apr 2008 13:55:28 +0200
>  Subject: Re: Updated 3534bis (was Re: Request for review of Ogg Media
>  Types: video/ogg, audio/ogg, application/ogg)
>  To: Ivo Emanuel Gon?alves <justivo[at]gmail[dot]com>
>
>  >>> 2. Usage of RFC 4281 "codecs" parameter? It seems
reasonably to include
>  >>> these parameters. Any issues with adding the parameter? And
if not, how
>  >>> do you want to describe the content of the file format, what
type of
>  >>> identifier space for the different content?
>  >>
>  >> We also discussed this prior to writing the draft.  The
conclusion was
>  >> that, while Ogg can encapsulate anything, most implementations
expect
>  >> only Xiph own codecs, so the three media types specified for each
type
>  >> of content is in theory enough to help implementations know what
they
>  >> are dealing with.  That not to mention that Skeleton already
informs
>  >> parsers of what is contained in Ogg, be the data served with or
>  >> without media types.
>  >>
>  >> We would like to avoid further complexity unless it is actually
necessary.
>  >
>  > I have to agree this is a difficult call. But there clearly are
systems
>  > that would like to determine what to do with Ogg file without having
to
>  > read the actual file. That include server side email filtering and
>  > transcoding. I would recommend that you actually introduce this as it
>  > helps in system where it is not desirable to download a file unless
it
>  > actually is usable. An soon anyone starts including a new codec or
>  > content into ogg files the utility of this parameter grows. So I
think
>  > it comes down to if you think if it has any potential to be a
commonly
>  > used format where additional formats will desirable.
>  >
>  > I (personally) will not insist but I think it would be good.
>
>  We need to reach a consensus on this issue and, if possible, soon. 
Comments?
>
>  RFC 4281, which describes codec parameters can be found here[1].
>
>  -Ivo
>
>  [1] http://www.rfc-editor.org/rfc/rfc4281.txt
>  _______________________________________________
>  Vorbis-dev mailing list
>  Vorbis-dev at xiph.org
>  http://lists.xiph.org/mailman/listinfo/vorbis-dev
>