Ogg Media Types

audio/ogg is defined as an even smaller subset within video/ogg because it is not intended to refer to visual content, creating a three-tier hierarchy: application/ogg (widest), video/ogg, audio/ogg (narrowest).

The 'application' top-level type for audio/video Ogg content is known to be problematic because it obfuscates the nature of video and audio content, motivating the introduction of dedicated video/ogg and audio/ogg types.

The .ogg file extension previously used for application/ogg is reassigned to audio/ogg (Vorbis-only) because historically some implementations expected .ogg files to contain solely Vorbis-encoded audio, leading to the new .ogx extension for application/ogg.

Ogg media types are intended for stream-based storage (files) and transport (TCP streams or pipes); separate RTP payload format types are used for real-time applications such as Theora, Vorbis, and Speex.

rtp, realtime

The use of Ogg Skeleton extension has been confirmed to not cause interoperability issues with existing implementations. The .ogg and .spx extensions for audio/ogg deliberately omit Skeleton requirements for backward compatibility with existing implementations.

application/ogg SHOULD only be used in situations where it is not appropriate to serve data under video/ogg or audio/ogg; data served under application/ogg SHOULD use the .ogx file extension and MUST contain an Ogg Skeleton logical bitstream.

registry

Content served under audio/ogg SHOULD have an Ogg Skeleton logical bitstream when using the default .oga file extension. The .ogg and .spx extensions require no Skeleton due to backward compatibility concerns.

Implementations that identify a logical bitstream that they cannot decode SHOULD ignore it while continuing to decode the ones they can, ensuring backward and forward compatibility.

Using Ogg Skeleton is REQUIRED for content served under the application/ogg type and RECOMMENDED for video/ogg and audio/ogg, as Skeleton contains identifiers to describe the different encapsulated data.

registry

video/ogg and audio/ogg SHOULD be used when dealing with video or audio content, respectively, in preference to application/ogg.

registry

video/ogg content SHOULD contain an Ogg Skeleton logical bitstream, and implementations interacting with video/ogg SHOULD support multiplexed bitstreams.

application/ogg is redefined for complex data (e.g., multitrack visual, audio, textual, and other time-continuously sampled data) not clearly video or audio. It uses file extension .ogx and Macintosh type code OggX. Data served under this type MUST contain an Ogg Skeleton logical bitstream.

registry

audio/ogg is defined for Ogg bitstreams predominantly containing audio data. It uses file extensions .oga (default), .ogg (Vorbis-only), and .spx (Speex-only), and Macintosh type code OggA.

registry

The 'codecs' parameter (defined in RFC 4281) may optionally be used with all three Ogg media types. Codec identifiers are mapped from binary header signatures to string values (e.g., '\x80theora' maps to 'theora', '\x01vorbis' maps to 'vorbis').

video/ogg is defined for Ogg bitstreams containing visual, audio, timed text, or any other material requiring a visual interface. It uses file extension .ogv and Macintosh type code OggV. Implementations SHOULD support multiplexed bitstreams.

registry

This document registers two new IANA media types (video/ogg and audio/ogg) and redefines the existing application/ogg media type, obsoleting RFC 3534.

registry

Implementations decoding Ogg in networking scenarios must ensure correct handling of manipulated bitstreams, buffer overflows, and similar issues arising from potentially hostile network data.

security

It is possible to author malicious Ogg bitstreams that request excessively large picture sizes or high sampling-rate audio. Implementations SHOULD protect themselves against this kind of resource exhaustion attack.

security

Ogg bitstreams may contain executable content; implementations SHOULD NOT execute such content without prior validation of its origin by the end-user.

security

Ogg provides no generic encryption or signing of itself or its contained bitstreams. External security mechanisms must be applied to provide content confidentiality and authenticity.

security, crypto

All three Ogg media types share the magic number 0x4f 0x67 0x67 0x53 (the string 'OggS') as the first four bytes of the bitstream.