[Vorbis-dev] Codec Parameter for Ogg media types

Conrad Parker conrad at metadecks.org
Sun Apr 13 17:57:44 PDT 2008


On 14/04/2008, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> 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.
>

I think it's a good idea too.

Then we can use "audio/ogg; codecs=vorbis" rather than the
unregistered "audio/vorbis" in skeleton.

It also means that we have a general way to name the codecs in a file
or network resource, to generate a menu etc.

Conrad.

>
>  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
>  >
>  _______________________________________________
>  Vorbis-dev mailing list
>  Vorbis-dev at xiph.org
>  http://lists.xiph.org/mailman/listinfo/vorbis-dev
>
>


More information about the Vorbis-dev mailing list