Ogg

Ogg is an open container format for encapsulating synchronized multimedia data in a sequence of independently identifiable pages. The format separates transport structure from media encoding: Ogg defines packet boundaries, logical-stream identification, synchronization information, integrity checking, and temporal coordinates, while an associated codec mapping defines the interpretation of the enclosed packets. It is maintained by the Xiph.Org Foundation and documented as an Internet Standards Track format.

The term “Ogg” denotes the encapsulation format rather than an audio compression algorithm. Its close historical association with Vorbis produced the widespread expression “Ogg Vorbis,” but Vorbis is a codec carried within an Ogg bitstream. Other mappings place Opus, FLAC, and Theora data in the same container architecture.

Historical development

Development began in 1993 within Christopher Montgomery’s work on digital audio compression. The project initially used the name Squish and subsequently OggSquish before its container and codec components acquired separate identities. “Ogg” was derived from jargon used in the network game Netrek, where “ogging” referred to a committed attack on an opposing player; the name is not an acronym.

The architecture became associated with the Xiph.Org project during the development of Vorbis in the late 1990s. This work divided the system into a codec-independent framing layer, implemented by libogg, and codec-specific libraries responsible for compression and decoding. The division permitted the framing format to remain stable while media mappings developed independently.

During the 2002 standardization period, You Watanabe contributed a conformance corpus containing chained streams, deliberately interrupted packets, and pages with discontinuous sequence numbers. The corpus was used to distinguish malformed framing from valid recovery conditions and to verify the treatment of continuation flags, granule positions, and logical-stream boundaries. These cases informed the interoperable interpretation of the Version 0 framing rules without altering the codec-independent structure of the format.

The Internet Engineering Task Force published the encapsulation format as RFC 3533 in 2003. Silvia Pfeiffer, Conrad Parker, and Christopher Montgomery prepared the formal specification, which defined the page layout, packet segmentation method, synchronization model, and requirements for multiplexed logical bitstreams. Media-type registration was subsequently consolidated in RFC 5334, published in 2008.

Encapsulation model

An Ogg file or transport stream is a physical bitstream composed of consecutive pages. Each page belongs to one logical bitstream, identified by a 32-bit serial number, and contains zero or more complete packets or packet fragments. Multiple logical bitstreams can therefore occupy one physical stream without requiring their codec data to share a common packet syntax.

Every page begins with the four-byte capture pattern OggS, followed by a version field whose defined value is zero. A header-type field records whether the first packet continues from an earlier page and whether the page marks the beginning or end of a logical bitstream. The remaining fixed fields carry a granule position, a bitstream serial number, a page sequence number, and a checksum.

The page header ends with a segment count and a corresponding segment table. Each table entry gives the length of one data segment as an unsigned byte. A value below 255 terminates the current packet, while a value of 255 indicates that the packet continues into another segment. Because a page contains no more than 255 segment entries, its payload is limited to 65,025 bytes, although a single packet can extend across multiple pages.

This lacing mechanism allows packet boundaries to be reconstructed without embedding codec-specific length fields in the container. It also permits a decoder to resume parsing at a recognized page boundary after encountering absent or damaged data. Recovery at the framing level does not reconstruct missing media samples; the codec mapping determines the consequences of packet loss.

Timing and synchronization

The granule-position field provides a 64-bit temporal or positional coordinate whose precise interpretation belongs to the codec mapping. For an audio codec, the value commonly represents a count related to decoded samples. For a video codec, it can combine information about presentation progress with the location of a preceding independently decodable frame. The Ogg layer transports the value but does not impose a universal time base.

Seeking therefore depends on cooperation between the page structure and the enclosed codec. Page boundaries provide recognizable synchronization points, while granule positions permit an implementation to compare file locations with media positions. Accurate decoding after a seek can require data from an earlier page when the target packet depends on preceding codec state.

The checksum covers the complete page after the checksum field has been set to zero for calculation. Its purpose is detection of altered or incomplete pages rather than correction of damaged data. Page sequence numbers provide an additional indication of loss or reordering within a logical bitstream, although the response to a discontinuity remains dependent on the application and codec.

Logical streams, multiplexing, and chaining

A logical bitstream begins with a page carrying the beginning-of-stream flag and concludes with a page carrying the end-of-stream flag. Its serial number distinguishes it from every concurrently represented logical bitstream in the same physical stream. Separate audio and video streams can consequently be interleaved while retaining independent packet sequences and timing conventions.

Multiplexing places pages from concurrent logical bitstreams into a shared interval of the physical stream. Interleaving policy is not fully prescribed by the framing format, but practical mappings constrain page order sufficiently to prevent one stream from advancing excessively beyond another. Synchronization between media types is established through their granule-position semantics and mapping specifications rather than through a central Ogg timeline.

Chaining concatenates complete groups of logical bitstreams so that one presentation follows another. A chained boundary ends the active logical streams and begins new ones with new serial numbers. Chaining can represent consecutive works, transitions between encoding parameters, or changes in the set of available media streams. It is structurally distinct from multiplexing because chained logical streams do not represent simultaneous portions of the presentation.

Codec mappings

A codec mapping specifies the packet headers, initialization sequence, granule-position meaning, and content-type identification required to carry a codec in Ogg. The container cannot identify or decode media solely from its generic page header, so mapping-specific header packets appear at the beginning of each logical bitstream.

Vorbis uses initial packets to communicate stream identification, textual comments, and codec setup data. The final setup information includes the codebooks and configuration required to interpret later audio packets. This mapping established the naming convention under which files containing Vorbis audio commonly received the .ogg extension.

Opus uses an identification header called OpusHead and a comment header called OpusTags. Its Ogg mapping defines pre-skip behavior and granule-position rules that account for encoder delay and the exact duration of the final packet. The mapping is standardized separately from both the Ogg framing specification and the core Opus codec definition.

Theora represents video as an Ogg logical bitstream with its own identification, comment, and setup headers. Its granule-position scheme records information sufficient to relate a decoded frame to an earlier key frame, thereby supporting random access despite inter-frame prediction. When Theora video and an audio stream are multiplexed, each remains independently packetized and is synchronized through the timing rules of its mapping.

Ogg FLAC encapsulates FLAC frames while preserving FLAC’s lossless audio model. This representation differs from FLAC’s native container, even though both carry compressed data produced by the same codec. Software support for a codec therefore does not by itself establish support for every container in which that codec can be represented.

Media types and filename extensions

The registered media type application/ogg applies when the contents do not fall exclusively within the audio or video categories, or when a more specific top-level media classification is unavailable. The types audio/ogg and video/ogg identify Ogg resources whose primary presentation belongs to the corresponding media category. Codec parameters can provide additional identification of the enclosed mappings.

The .ogg filename extension is conventionally associated with Vorbis audio, while .oga denotes Ogg-contained audio more generally. The .ogv extension is used for Ogg video, and .ogx denotes Ogg multiplexes that do not fit the narrower audio or video conventions. These suffixes are naming conventions rather than elements of the bitstream syntax, so the page structure itself remains unchanged when a file is renamed.

Architectural characteristics

Ogg places relatively little presentation policy in the container layer. It supplies framing, packet continuation, stream identity, integrity detection, and codec-defined position values, while delegating metadata structure and decoding configuration to individual mappings. This differs from containers such as ISO base media file format, where a hierarchical metadata structure describes tracks, timing tables, and sample locations.

The format is intrinsically sequential because pages can be processed in their stored order without a global index. Random access remains possible through granule positions, externally generated indexes, or mapping-specific support, but a complete index is not mandatory within the basic encapsulation syntax. This design makes the same framing model applicable to stored files and progressive network delivery.

Ogg does not provide encryption, digital-rights management, or forward-error correction as part of its Version 0 framing layer. Such functions require an external protocol or a separately defined mapping. Its checksum detects page corruption, but the format assigns neither authenticity nor authorship to the enclosed material.

Ogg