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

On 5/24/08, Conrad Parker <conrad at metadecks.org>
wrote:
> The magic is not always char[8] -- it's an arbitrary number of
> characters, and as far as I know there is no official limit.
I was under the impression that 8 was the limit.  Thus the extra white
space JM adds on Speex and CELT magics.  I may be wrong, though.
> So it's 7 for Vorbis and Theora, 5 for FLAC
So char[7]: '\x01vorbis', char[7]: '\x80theora' and char[5]:
'\177FLAC'?
> immediately after '\177FLAC' is a version field, which is not part
of the
> codec ident string but is within the first 8 bytes.
I don't think that interferes with anything.  We are talking about the
essential part needed to be detected by applications.
> What you've listed for CMML is correct, and I'm pretty sure the
> strings are correct for Vorbis, Theora, Speex, and PCM.
Good, good.
> Also I don't know if the Dirac, MIDI, CELT or Kate mappings are yet
> finalized?
Kate is AFAIK finalized; that's the impression I get from talks with
ogg.k.ogg.k.

Nobody's touched MIDI in years, so that's probably how it will stay.

Considering the similarity between the CELT and Speex strings (the
extra white space thingy) I don't think JM's changing it.

Dirac is the only one I'm not sure, since this one here's the recent
string.  The magic used to be different, and I'm not sure if whoever's
working on Dirac may have a change of ideas.

Anyway, the essential for the document is that no errors can be
present.  Changes and newer codecs may be added later on an update to
the document.

Thanks.

-Ivo

On 24-May-08, at 9:26 AM, Ivo Emanuel Gon?alves wrote:
> I don't think that interferes with anything.  We are talking about  
> the essential part needed to be detected by applications.
Conrad was just saying that the way you described the ids was  
inconsistent. One column said read 8 chars, the other said compare  
with a string that might be less than eight characters.
> Dirac is the only one I'm not sure, since this one here's the  
> recent string.
It's supposed to be finalized though there many be some granulepos  
issues still in current implementations. I don't expect the BBCD\0  
magic to change.

OggMNG defines the following magics:

char[8]: "\211PNG\r\n\032\n" png
char[8]: "\212MNG\r\n\032\n" mng
char[8]: "\213JNG\r\n\032\n" jng

Are the 'Codecs Parameter' values from a different namespace from the  
media-types? Do we define a mapping where there is one, e.g. vorbis  
is audio/vorbis?

And there's OggY4M which uses char[9]: "YUV4MPEG2" but that's
in no
way finalized.

  -r

On 5/24/08, Ralph Giles <giles at xiph.org> wrote:
> It's supposed to be finalized though there many be some granulepos
> issues still in current implementations. I don't expect the BBCD\0
> magic to change.
Great.
> OggMNG defines the following magics:
>
> char[8]: "\211PNG\r\n\032\n" png
> char[8]: "\212MNG\r\n\032\n" mng
> char[8]: "\213JNG\r\n\032\n" jng
Ah, yes, I had forgotten about image encapsulation!  Doesn't OggSpots
also cover standard JPEG?  Should we add it, too?
> Are the 'Codecs Parameter' values from a different namespace from
the
> media-types? Do we define a mapping where there is one, e.g. vorbis
> is audio/vorbis?
If I understand your question correctly, the answer is yes and no.  It
is part of the media types regardless of namespace, but it's just a
string to describe each contained codec not a specific media type like
what is used in Skeleton.

Here's an example: video/ogg; codecs="theora, vorbis, kate"
> And there's OggY4M which uses char[9]: "YUV4MPEG2" but
that's in no
> way finalized.
So this shouldn't be added, right?

-Ivo

On Sun, May 25, 2008 at 2:53 AM, Ralph Giles <giles at xiph.org>
wrote:
> On 24-May-08, at 9:26 AM, Ivo Emanuel Gon?alves wrote:
>
> And there's OggY4M which uses char[9]: "YUV4MPEG2" but
that's in no
> way finalized.
I was unable to find any documentation on this on the Web. Would you
have a link to the mapping?

BTW, I have now finalized a first version of the codecs table on the
wiki: http://wiki.xiph.org/index.php/MIMETypesCodecs. Please assume
typos and check it...

We should probably put a link to this page on the wiki front page
(wiki.xiph.org). I don't seem to be able to edit that protected
wikipage though, so whoever has the rights, please do hook it in.

Cheers,
Silvia.