[ogg-dev] How Ogg mappings translate into the codecs parameter in Ogg media types

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Tue May 27 16:25:02 PDT 2008

On Wed, May 28, 2008 at 8:17 AM, Ivo Emanuel Gonçalves
<justivo at gmail.com> wrote:
> Silvia,
> I don't think I follow your line of thought.
> On 5/27/08, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
>> I was just having a thought this morning: we should probably include
>> the version information into the codec identification bits.
> What version information?  Like libvorbis 1.2.1?  If so, I can't see
> much of a point in that.

I am not talking about versions of libraries, but versions of codecs.
Most codecs have a version information field since codecs progress in
their specifications, too. It was this field that I referred to.

>> It will make it easier to then re-use the table for mime-types for codecs as
>> we go and do RTP/RTSP specifications.
> How?  RTP specifications are using their own media types, sometimes
> coupled with "side-kick"  (e.g. audio/vorbis-config).

I've never heard of such a mime type. Yet, I know that audio/vorbis is
being used as mimetype in RTP to identify the vorbis codec.

> And what good
> there would be in using a version information here?  All Vorbis
> streams for instance are (hopefully) supposed to work in past and
> future decoders.

If we were working under the assumption that a codec *specification*
never changes in it's lifetime, then that would be a correct
assumption. (Of course: libraries and applications change and have
their own versioning information, but this is not what I am referring
to). There may be some codecs that rather change their name than
become version 2. But there are others that actually have a version
field and that was the field I referred to. FLAC and CMML for example
have version fields.

Hope this clarifies what I am suggesting.


More information about the ogg-dev mailing list