[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