Subject: Fwd: Re: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes)

From: "Michael Smith" <[email-masked]>
Date: Fri, 24 Jan 2003 06:58:38 -0000

Oops, resending - hit 'reply' instead of 'reply to all'...

Allison Mankin <[email-masked]> said:

> Silvia, AVT WG, Chairs,
> 
> We IESG passed draft-walleij-ogg-mediatype-08.txt as a Proposed
> Standard today.  It had had a four week Last Call some time back and
> was not changed, other than now having the internet-draft available to
> document the fileformat.  Congratulations!
> 
> The accompanying i-d, draft-pfeiffer-ogg-fileformat, was on the agenda
> as well and Harald Alvestrand raised a technical question that needs
> to be resolved before we can progress it as Informational.  Harald's
> written question:
> 
>   Technical omission (I think): The document says that the BOS page
>   "contains information to identify the codec type and any additional
>   information to set up the decoding process.  The format of that page
>   is therefore dependent on the codec and therefore MUST be given in
>   the encoding specification of that logical bitstream type."

I'd suggest a rewording of "and any information ..." to "and MAY contain
information to set up the decoding process". Vorbis, for example, contains
some but not all of the setup data in this header (BOS page) - most of the
setup information is in the 3rd header packet (the codebook packet). This
makes it clearer that Ogg doesn't require ALL setup info in the BOS page.

Also, the format does not mandate the following, but I think perhaps we should
considering strongly suggesting it (it's done by all existing Ogg-encapsulated
codecs, and is very useful generally): (something like this) "The BOS page
SHOULD also contain information about the type of the output (decompressed)
media - for example, for audio, it should contain sample rate and number of
channels" (that needs a bit of editorial attention, but I think it'd be a
worthwhile addition).

> 
>   It's pretty clear that OGG players can identify which codec is being
>   used. But this document does not say which bytes of the BOS page can
>   be used to identify the codec. (first 4 bytes? first 16 bytes? up to
>   the first NUL?)
> 

Again, based on vorbis as an example (for the spec doesn't explicitly state
this), any leading part of the data (i.e. packet contents, so these are not
the absolute leading bytes in the stream, since there is the page header
first) in this first page. Vorbis uses the first 7 bytes (0x01, 0x76, 0x6f,
0x72, 0x62, 0x69, 0x73 -- which is a leading 0x01 followed by the ascii values
for "vorbis"), but the intent is to not have a single fixed-size identifier.
We should, however, specify a _maximum_ length for this).

Mike

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 24 Jan 2003 10:07:07 +0100

--On fredag, januar 24, 2003 06:58:38 +0000 Michael Smith 
<[email-masked]> wrote:

> Again, based on vorbis as an example (for the spec doesn't explicitly
> state this), any leading part of the data (i.e. packet contents, so these
> are not the absolute leading bytes in the stream, since there is the page
> header first) in this first page. Vorbis uses the first 7 bytes (0x01,
> 0x76, 0x6f, 0x72, 0x62, 0x69, 0x73 -- which is a leading 0x01 followed by
> the ascii values for "vorbis"), but the intent is to not have a single
> fixed-size identifier. We should, however, specify a _maximum_ length for
> this).

followup..... the IETF's been dealing with multilevel protocols for some 
years, so identifying the "protocol at the next layer" is something we're 
used to... not trying to say what's the right way, just musing about the 
problem....

you've basically got two problems:

1) how to make sure there's information enough to identify the codec, and 
information enough to know when the codec has been uniquely identified?
(it would be silly if players refused to play 0x01 + "vorbis" + 0x01 
because all the sound they had been tested on had a 0x00 in the position 
after the "vorbis" string, and the player checked the values of 8 bytes, 
for instance; otoh, 0x01 + "vorbiz" is probably a different codec, so you 
should check at least 7 bytes, not 6)
(btw, my Linux Mandrake "magic" file claims that the byte after "vorbis" is 
the 32-bit version number, and zero is the only known value, I think...)

2) how to make sure no two codecs pick the same identifier string?
(the "registry" problem)

the last is usually not a problem until some name becomes "popular" - but 
think about the number of formats that have been using the .doc file name 
ending on the Windows platform for an example of collisions.... if you 
solve that problem by establishing some kind of registry (rather than 
"trust to luck and goodwill"), you also have a convenient place to store 
pointers to the specifications of those formats.....

(In my personal .ogg collection, there are no examples of anything but the 
vorbis codec, unfortunately... and all of it has been encoded with a single 
codec, so this is not much of a test suite....)

                        Harald

---

From: Linus Walleij <[email-masked]>
Date: Mon, 27 Jan 2003 13:02:51 +0100 (MET)

> 2) how to make sure no two codecs pick the same identifier string?

This is a natural pointer to the IANA, in case you want to establish
something rock-solid. Not that I know if they would like to do this, but
it it is to be a widely accepted standard for codec identification, IANA
would be the place to store the strings.

Someone who knows how registry issues have been handled in the past,
please step up.

Alternatively, you could list the magic strings available today, and
require extensions to file further informational RFCs for the additions.
(Sort of sticky and slow in comparison to IANA handling it.)

I also would like to hear the "official" Xiph.org view on this subject.
Michael?

Yours,
Linus Walleij

---

From: Stephen Casner <[email-masked]>
Date: Mon, 27 Jan 2003 12:39:40 -0800 (PST)

> would be the place to store the strings.

I agree.  And my take is that therefore ogg should not be a MIME
subtype.  Instead, vorbis should be a MIME subtype, and ogg should be
(an aspect of) one encoding for the vorbis subtype, just like the RTP
payload format is another encoding for the vorbis subtype.

The MIME registration for vorbis can explain these different
encodings, and can give the "magic number" string which can be the
same as the MIME subtype name (and therefore unique).

> (Sort of sticky and slow in comparison to IANA handling it.)

The magic strings already in use would need to be registered as MIME
subtypes (assuming no conflicts with subtypes already registered).

                                                        -- Steve