ogg dev - May 2008 - How Ogg mappings translate into the codecs parameter in Ogg media types

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.
> 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).  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.

-Ivo

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.

Regards,
Silvia.

On 5/28/08, Silvia Pfeiffer <silviapfeiffer1 at gmail.com>
wrote:
> Hope this clarifies what I am suggesting.
It did.  Thank you.
> FLAC and CMML for example have version fields.
How many other "in-house" codecs have one?  This may be worth knowing.

-Ivo

2008/5/28 Silvia Pfeiffer <silviapfeiffer1 at
gmail.com>:
>
> I am not talking about versions of libraries, but versions of codecs.
> ...
> FLAC and CMML for example have version fields.
(A bit pedantic, but) the FLAC version field at bytes 5 and 6 refers
to the version of the mapping (of FLAC into Ogg), not to the version
of the FLAC codec.

Conrad.