[vorbis-dev] audio/vorbis media type registration

[Ralph Giles]

On Mon, May 14, 2001 at 11:03:40PM +0200, Linus Walleij wrote:

> Encoding Considerations:
> 
>         The vorbis audio data is usually wrapped inside an OggSQUISH
>         bitstream, see [OGG].

I would not say 'OggSquish'. I suspect the usage on the website is
historical, and in any case there is another (lossless) audio codec
called 'Squish' so it's confusing to use that for the container format.
We've been calling it 'Ogg' or the 'Ogg bitream format'.

> Security Considerations:
> 
>         Ideally, the vorbis file can not contain security-violating code
>         as the format is highly specified, see [VORBIS] and/or [COLEMAN].
>         However, fields can be abused if the recieving decoder
>         implementation has errors or extensions that make it possible
>         to embed interpretative or object code. The recieveing decoder
>         must therefore take these issues into account, and under no
>         circumstances allow untrusted code to be executed.

Note that Ogg, as a container format, can be used to encapsulate any
sort of data you like, including executable content. That's a separate
issue from what a given vorbis implementation might do with maliciously
constructed audio packets, which does not itself have spec-level
security issues.

> Interoperability considerations:
> 
>         The vorbis format has proved to be widely implementable across
>         different computing platforms. An example implementation exists
>         that has been compiled on numerous platforms.

'A broadly portable reference implemenation is available under a BSD
license.' ?

>                          If vorbis files were to be delivered without
>                          the OggSQUISH header the "vorbis" string would
>                          appear at offset 0x01. This should never occur.

This point has been somewhat made by others. The description you give
above applies solely to vorbis audio data in an ogg bitstream. One could
easily have both ogg bitstreams that don't begin with the 'vorbis'
header (not a concern here) and one can easily have vorbis audio data
within another 'movie' or container format. In the latter case, I think
it's appropriate to use the mimetype assigned to that other format, and
reserve audio/vorbis for ogg-embedded vorbis data.

The 'raw vorbis packets' case you describe is not something I think
we'd ever want people to distribute. Could someone comment on how this
would interact with the rtp/rtsp streaming delivery?

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.