cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Network Working Group S. Pfeiffer cannam@86: Request for Comments: 3533 CSIRO cannam@86: Category: Informational May 2003 cannam@86: cannam@86: cannam@86: The Ogg Encapsulation Format Version 0 cannam@86: cannam@86: Status of this Memo cannam@86: cannam@86: This memo provides information for the Internet community. It does cannam@86: not specify an Internet standard of any kind. Distribution of this cannam@86: memo is unlimited. cannam@86: cannam@86: Copyright Notice cannam@86: cannam@86: Copyright (C) The Internet Society (2003). All Rights Reserved. cannam@86: cannam@86: Abstract cannam@86: cannam@86: This document describes the Ogg bitstream format version 0, which is cannam@86: a general, freely-available encapsulation format for media streams. cannam@86: It is able to encapsulate any kind and number of video and audio cannam@86: encoding formats as well as other data streams in a single bitstream. cannam@86: cannam@86: Terminology cannam@86: cannam@86: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", cannam@86: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this cannam@86: document are to be interpreted as described in BCP 14, RFC 2119 [2]. cannam@86: cannam@86: Table of Contents cannam@86: cannam@86: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 cannam@86: 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 cannam@86: 3. Requirements for a generic encapsulation format . . . . . . . 3 cannam@86: 4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . . 3 cannam@86: 5. The encapsulation process . . . . . . . . . . . . . . . . . . 6 cannam@86: 6. The Ogg page format . . . . . . . . . . . . . . . . . . . . . 9 cannam@86: 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 cannam@86: 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 cannam@86: A. Glossary of terms and abbreviations . . . . . . . . . . . . . 13 cannam@86: B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 cannam@86: Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 cannam@86: Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 1] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: 1. Introduction cannam@86: cannam@86: The Ogg bitstream format has been developed as a part of a larger cannam@86: project aimed at creating a set of components for the coding and cannam@86: decoding of multimedia content (codecs) which are to be freely cannam@86: available and freely re-implementable, both in software and in cannam@86: hardware for the computing community at large, including the Internet cannam@86: community. It is the intention of the Ogg developers represented by cannam@86: Xiph.Org that it be usable without intellectual property concerns. cannam@86: cannam@86: This document describes the Ogg bitstream format and how to use it to cannam@86: encapsulate one or several media bitstreams created by one or several cannam@86: encoders. The Ogg transport bitstream is designed to provide cannam@86: framing, error protection and seeking structure for higher-level cannam@86: codec streams that consist of raw, unencapsulated data packets, such cannam@86: as the Vorbis audio codec or the upcoming Tarkin and Theora video cannam@86: codecs. It is capable of interleaving different binary media and cannam@86: other time-continuous data streams that are prepared by an encoder as cannam@86: a sequence of data packets. Ogg provides enough information to cannam@86: properly separate data back into such encoder created data packets at cannam@86: the original packet boundaries without relying on decoding to find cannam@86: packet boundaries. cannam@86: cannam@86: Please note that the MIME type application/ogg has been registered cannam@86: with the IANA [1]. cannam@86: cannam@86: 2. Definitions cannam@86: cannam@86: For describing the Ogg encapsulation process, a set of terms will be cannam@86: used whose meaning needs to be well understood. Therefore, some of cannam@86: the most fundamental terms are defined now before we start with the cannam@86: description of the requirements for a generic media stream cannam@86: encapsulation format, the process of encapsulation, and the concrete cannam@86: format of the Ogg bitstream. See the Appendix for a more complete cannam@86: glossary. cannam@86: cannam@86: The result of an Ogg encapsulation is called the "Physical (Ogg) cannam@86: Bitstream". It encapsulates one or several encoder-created cannam@86: bitstreams, which are called "Logical Bitstreams". A logical cannam@86: bitstream, provided to the Ogg encapsulation process, has a cannam@86: structure, i.e., it is split up into a sequence of so-called cannam@86: "Packets". The packets are created by the encoder of that logical cannam@86: bitstream and represent meaningful entities for that encoder only cannam@86: (e.g., an uncompressed stream may use video frames as packets). They cannam@86: do not contain boundary information - strung together they appear to cannam@86: be streams of random bytes with no landmarks. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 2] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: Please note that the term "packet" is not used in this document to cannam@86: signify entities for transport over a network. cannam@86: cannam@86: 3. Requirements for a generic encapsulation format cannam@86: cannam@86: The design idea behind Ogg was to provide a generic, linear media cannam@86: transport format to enable both file-based storage and stream-based cannam@86: transmission of one or several interleaved media streams independent cannam@86: of the encoding format of the media data. Such an encapsulation cannam@86: format needs to provide: cannam@86: cannam@86: o framing for logical bitstreams. cannam@86: cannam@86: o interleaving of different logical bitstreams. cannam@86: cannam@86: o detection of corruption. cannam@86: cannam@86: o recapture after a parsing error. cannam@86: cannam@86: o position landmarks for direct random access of arbitrary positions cannam@86: in the bitstream. cannam@86: cannam@86: o streaming capability (i.e., no seeking is needed to build a 100% cannam@86: complete bitstream). cannam@86: cannam@86: o small overhead (i.e., use no more than approximately 1-2% of cannam@86: bitstream bandwidth for packet boundary marking, high-level cannam@86: framing, sync and seeking). cannam@86: cannam@86: o simplicity to enable fast parsing. cannam@86: cannam@86: o simple concatenation mechanism of several physical bitstreams. cannam@86: cannam@86: All of these design considerations have been taken into consideration cannam@86: for Ogg. Ogg supports framing and interleaving of logical cannam@86: bitstreams, seeking landmarks, detection of corruption, and stream cannam@86: resynchronisation after a parsing error with no more than cannam@86: approximately 1-2% overhead. It is a generic framework to perform cannam@86: encapsulation of time-continuous bitstreams. It does not know any cannam@86: specifics about the codec data that it encapsulates and is thus cannam@86: independent of any media codec. cannam@86: cannam@86: 4. The Ogg bitstream format cannam@86: cannam@86: A physical Ogg bitstream consists of multiple logical bitstreams cannam@86: interleaved in so-called "Pages". Whole pages are taken in order cannam@86: from multiple logical bitstreams multiplexed at the page level. The cannam@86: logical bitstreams are identified by a unique serial number in the cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 3] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: header of each page of the physical bitstream. This unique serial cannam@86: number is created randomly and does not have any connection to the cannam@86: content or encoder of the logical bitstream it represents. Pages of cannam@86: all logical bitstreams are concurrently interleaved, but they need cannam@86: not be in a regular order - they are only required to be consecutive cannam@86: within the logical bitstream. Ogg demultiplexing reconstructs the cannam@86: original logical bitstreams from the physical bitstream by taking the cannam@86: pages in order from the physical bitstream and redirecting them into cannam@86: the appropriate logical decoding entity. cannam@86: cannam@86: Each Ogg page contains only one type of data as it belongs to one cannam@86: logical bitstream only. Pages are of variable size and have a page cannam@86: header containing encapsulation and error recovery information. Each cannam@86: logical bitstream in a physical Ogg bitstream starts with a special cannam@86: start page (bos=beginning of stream) and ends with a special page cannam@86: (eos=end of stream). cannam@86: cannam@86: The bos page contains information to uniquely identify the codec type cannam@86: and MAY contain information to set up the decoding process. The bos cannam@86: page SHOULD also contain information about the encoded media - for cannam@86: example, for audio, it should contain the sample rate and number of cannam@86: channels. By convention, the first bytes of the bos page contain cannam@86: magic data that uniquely identifies the required codec. It is the cannam@86: responsibility of anyone fielding a new codec to make sure it is cannam@86: possible to reliably distinguish his/her codec from all other codecs cannam@86: in use. There is no fixed way to detect the end of the codec- cannam@86: identifying marker. The format of the bos page is dependent on the cannam@86: codec and therefore MUST be given in the encapsulation specification cannam@86: of that logical bitstream type. Ogg also allows but does not require cannam@86: secondary header packets after the bos page for logical bitstreams cannam@86: and these must also precede any data packets in any logical cannam@86: bitstream. These subsequent header packets are framed into an cannam@86: integral number of pages, which will not contain any data packets. cannam@86: So, a physical bitstream begins with the bos pages of all logical cannam@86: bitstreams containing one initial header packet per page, followed by cannam@86: the subsidiary header packets of all streams, followed by pages cannam@86: containing data packets. cannam@86: cannam@86: The encapsulation specification for one or more logical bitstreams is cannam@86: called a "media mapping". An example for a media mapping is "Ogg cannam@86: Vorbis", which uses the Ogg framework to encapsulate Vorbis-encoded cannam@86: audio data for stream-based storage (such as files) and transport cannam@86: (such as TCP streams or pipes). Ogg Vorbis provides the name and cannam@86: revision of the Vorbis codec, the audio rate and the audio quality on cannam@86: the Ogg Vorbis bos page. It also uses two additional header pages cannam@86: per logical bitstream. The Ogg Vorbis bos page starts with the byte cannam@86: 0x01, followed by "vorbis" (a total of 7 bytes of identifier). cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 4] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: Ogg knows two types of multiplexing: concurrent multiplexing (so- cannam@86: called "Grouping") and sequential multiplexing (so-called cannam@86: "Chaining"). Grouping defines how to interleave several logical cannam@86: bitstreams page-wise in the same physical bitstream. Grouping is for cannam@86: example needed for interleaving a video stream with several cannam@86: synchronised audio tracks using different codecs in different logical cannam@86: bitstreams. Chaining on the other hand, is defined to provide a cannam@86: simple mechanism to concatenate physical Ogg bitstreams, as is often cannam@86: needed for streaming applications. cannam@86: cannam@86: In grouping, all bos pages of all logical bitstreams MUST appear cannam@86: together at the beginning of the Ogg bitstream. The media mapping cannam@86: specifies the order of the initial pages. For example, the grouping cannam@86: of a specific Ogg video and Ogg audio bitstream may specify that the cannam@86: physical bitstream MUST begin with the bos page of the logical video cannam@86: bitstream, followed by the bos page of the audio bitstream. Unlike cannam@86: bos pages, eos pages for the logical bitstreams need not all occur cannam@86: contiguously. Eos pages may be 'nil' pages, that is, pages cannam@86: containing no content but simply a page header with position cannam@86: information and the eos flag set in the page header. Each grouped cannam@86: logical bitstream MUST have a unique serial number within the scope cannam@86: of the physical bitstream. cannam@86: cannam@86: In chaining, complete logical bitstreams are concatenated. The cannam@86: bitstreams do not overlap, i.e., the eos page of a given logical cannam@86: bitstream is immediately followed by the bos page of the next. Each cannam@86: chained logical bitstream MUST have a unique serial number within the cannam@86: scope of the physical bitstream. cannam@86: cannam@86: It is possible to consecutively chain groups of concurrently cannam@86: multiplexed bitstreams. The groups, when unchained, MUST stand on cannam@86: their own as a valid concurrently multiplexed bitstream. The cannam@86: following diagram shows a schematic example of such a physical cannam@86: bitstream that obeys all the rules of both grouped and chained cannam@86: multiplexed bitstreams. cannam@86: cannam@86: physical bitstream with pages of cannam@86: different logical bitstreams grouped and chained cannam@86: ------------------------------------------------------------- cannam@86: |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#| cannam@86: ------------------------------------------------------------- cannam@86: bos bos bos eos eos eos bos eos cannam@86: cannam@86: In this example, there are two chained physical bitstreams, the first cannam@86: of which is a grouped stream of three logical bitstreams A, B, and C. cannam@86: The second physical bitstream is chained after the end of the grouped cannam@86: bitstream, which ends after the last eos page of all its grouped cannam@86: logical bitstreams. As can be seen, grouped bitstreams begin cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 5] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: together - all of the bos pages MUST appear before any data pages. cannam@86: It can also be seen that pages of concurrently multiplexed bitstreams cannam@86: need not conform to a regular order. And it can be seen that a cannam@86: grouped bitstream can end long before the other bitstreams in the cannam@86: group end. cannam@86: cannam@86: Ogg does not know any specifics about the codec data except that each cannam@86: logical bitstream belongs to a different codec, the data from the cannam@86: codec comes in order and has position markers (so-called "Granule cannam@86: positions"). Ogg does not have a concept of 'time': it only knows cannam@86: about sequentially increasing, unitless position markers. An cannam@86: application can only get temporal information through higher layers cannam@86: which have access to the codec APIs to assign and convert granule cannam@86: positions or time. cannam@86: cannam@86: A specific definition of a media mapping using Ogg may put further cannam@86: constraints on its specific use of the Ogg bitstream format. For cannam@86: example, a specific media mapping may require that all the eos pages cannam@86: for all grouped bitstreams need to appear in direct sequence. An cannam@86: example for a media mapping is the specification of "Ogg Vorbis". cannam@86: Another example is the upcoming "Ogg Theora" specification which cannam@86: encapsulates Theora-encoded video data and usually comes multiplexed cannam@86: with a Vorbis stream for an Ogg containing synchronised audio and cannam@86: video. As Ogg does not specify temporal relationships between the cannam@86: encapsulated concurrently multiplexed bitstreams, the temporal cannam@86: synchronisation between the audio and video stream will be specified cannam@86: in this media mapping. To enable streaming, pages from various cannam@86: logical bitstreams will typically be interleaved in chronological cannam@86: order. cannam@86: cannam@86: 5. The encapsulation process cannam@86: cannam@86: The process of multiplexing different logical bitstreams happens at cannam@86: the level of pages as described above. The bitstreams provided by cannam@86: encoders are however handed over to Ogg as so-called "Packets" with cannam@86: packet boundaries dependent on the encoding format. The process of cannam@86: encapsulating packets into pages will be described now. cannam@86: cannam@86: From Ogg's perspective, packets can be of any arbitrary size. A cannam@86: specific media mapping will define how to group or break up packets cannam@86: from a specific media encoder. As Ogg pages have a maximum size of cannam@86: about 64 kBytes, sometimes a packet has to be distributed over cannam@86: several pages. To simplify that process, Ogg divides each packet cannam@86: into 255 byte long chunks plus a final shorter chunk. These chunks cannam@86: are called "Ogg Segments". They are only a logical construct and do cannam@86: not have a header for themselves. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 6] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: A group of contiguous segments is wrapped into a variable length page cannam@86: preceded by a header. A segment table in the page header tells about cannam@86: the "Lacing values" (sizes) of the segments included in the page. A cannam@86: flag in the page header tells whether a page contains a packet cannam@86: continued from a previous page. Note that a lacing value of 255 cannam@86: implies that a second lacing value follows in the packet, and a value cannam@86: of less than 255 marks the end of the packet after that many cannam@86: additional bytes. A packet of 255 bytes (or a multiple of 255 bytes) cannam@86: is terminated by a lacing value of 0. Note also that a 'nil' (zero cannam@86: length) packet is not an error; it consists of nothing more than a cannam@86: lacing value of zero in the header. cannam@86: cannam@86: The encoding is optimized for speed and the expected case of the cannam@86: majority of packets being between 50 and 200 bytes large. This is a cannam@86: design justification rather than a recommendation. This encoding cannam@86: both avoids imposing a maximum packet size as well as imposing cannam@86: minimum overhead on small packets. In contrast, e.g., simply using cannam@86: two bytes at the head of every packet and having a max packet size of cannam@86: 32 kBytes would always penalize small packets (< 255 bytes, the cannam@86: typical case) with twice the segmentation overhead. Using the lacing cannam@86: values as suggested, small packets see the minimum possible byte- cannam@86: aligned overhead (1 byte) and large packets (>512 bytes) see a fairly cannam@86: constant ~0.5% overhead on encoding space. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 7] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: The following diagram shows a schematic example of a media mapping cannam@86: using Ogg and grouped logical bitstreams: cannam@86: cannam@86: logical bitstream with packet boundaries cannam@86: ----------------------------------------------------------------- cannam@86: > | packet_1 | packet_2 | packet_3 | < cannam@86: ----------------------------------------------------------------- cannam@86: cannam@86: |segmentation (logically only) cannam@86: v cannam@86: cannam@86: packet_1 (5 segments) packet_2 (4 segs) p_3 (2 segs) cannam@86: ------------------------------ -------------------- ------------ cannam@86: .. |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | .. cannam@86: ------------------------------ -------------------- ------------ cannam@86: cannam@86: | page encapsulation cannam@86: v cannam@86: cannam@86: page_1 (packet_1 data) page_2 (pket_1 data) page_3 (packet_2 data) cannam@86: ------------------------ ---------------- ------------------------ cannam@86: |H|------------------- | |H|----------- | |H|------------------- | cannam@86: |D||seg_1|seg_2|seg_3| | |D|seg_4|s_5 | | |D||seg_1|seg_2|seg_3| | ... cannam@86: |R|------------------- | |R|----------- | |R|------------------- | cannam@86: ------------------------ ---------------- ------------------------ cannam@86: cannam@86: | cannam@86: pages of | cannam@86: other --------| | cannam@86: logical ------- cannam@86: bitstreams | MUX | cannam@86: ------- cannam@86: | cannam@86: v cannam@86: cannam@86: page_1 page_2 page_3 cannam@86: ------ ------ ------- ----- ------- cannam@86: ... || | || | || | || | || | ... cannam@86: ------ ------ ------- ----- ------- cannam@86: physical Ogg bitstream cannam@86: cannam@86: In this example we take a snapshot of the encapsulation process of cannam@86: one logical bitstream. We can see part of that bitstream's cannam@86: subdivision into packets as provided by the codec. The Ogg cannam@86: encapsulation process chops up the packets into segments. The cannam@86: packets in this example are rather large such that packet_1 is split cannam@86: into 5 segments - 4 segments with 255 bytes and a final smaller one. cannam@86: Packet_2 is split into 4 segments - 3 segments with 255 bytes and a cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 8] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: final very small one - and packet_3 is split into two segments. The cannam@86: encapsulation process then creates pages, which are quite small in cannam@86: this example. Page_1 consists of the first three segments of cannam@86: packet_1, page_2 contains the remaining 2 segments from packet_1, and cannam@86: page_3 contains the first three pages of packet_2. Finally, this cannam@86: logical bitstream is multiplexed into a physical Ogg bitstream with cannam@86: pages of other logical bitstreams. cannam@86: cannam@86: 6. The Ogg page format cannam@86: cannam@86: A physical Ogg bitstream consists of a sequence of concatenated cannam@86: pages. Pages are of variable size, usually 4-8 kB, maximum 65307 cannam@86: bytes. A page header contains all the information needed to cannam@86: demultiplex the logical bitstreams out of the physical bitstream and cannam@86: to perform basic error recovery and landmarks for seeking. Each page cannam@86: is a self-contained entity such that the page decode mechanism can cannam@86: recognize, verify, and handle single pages at a time without cannam@86: requiring the overall bitstream. cannam@86: cannam@86: The Ogg page header has the following format: cannam@86: cannam@86: 0 1 2 3 cannam@86: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | capture_pattern: Magic number for page start "OggS" | 0-3 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | version | header_type | granule_position | 4-7 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | | 8-11 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | | bitstream_serial_number | 12-15 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | | page_sequence_number | 16-19 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | | CRC_checksum | 20-23 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | |page_segments | segment_table | 24-27 cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: | ... | 28- cannam@86: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cannam@86: cannam@86: The LSb (least significant bit) comes first in the Bytes. Fields cannam@86: with more than one byte length are encoded LSB (least significant cannam@86: byte) first. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 9] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: The fields in the page header have the following meaning: cannam@86: cannam@86: 1. capture_pattern: a 4 Byte field that signifies the beginning of a cannam@86: page. It contains the magic numbers: cannam@86: cannam@86: 0x4f 'O' cannam@86: cannam@86: 0x67 'g' cannam@86: cannam@86: 0x67 'g' cannam@86: cannam@86: 0x53 'S' cannam@86: cannam@86: It helps a decoder to find the page boundaries and regain cannam@86: synchronisation after parsing a corrupted stream. Once the cannam@86: capture pattern is found, the decoder verifies page sync and cannam@86: integrity by computing and comparing the checksum. cannam@86: cannam@86: 2. stream_structure_version: 1 Byte signifying the version number of cannam@86: the Ogg file format used in this stream (this document specifies cannam@86: version 0). cannam@86: cannam@86: 3. header_type_flag: the bits in this 1 Byte field identify the cannam@86: specific type of this page. cannam@86: cannam@86: * bit 0x01 cannam@86: cannam@86: set: page contains data of a packet continued from the previous cannam@86: page cannam@86: cannam@86: unset: page contains a fresh packet cannam@86: cannam@86: * bit 0x02 cannam@86: cannam@86: set: this is the first page of a logical bitstream (bos) cannam@86: cannam@86: unset: this page is not a first page cannam@86: cannam@86: * bit 0x04 cannam@86: cannam@86: set: this is the last page of a logical bitstream (eos) cannam@86: cannam@86: unset: this page is not a last page cannam@86: cannam@86: 4. granule_position: an 8 Byte field containing position information. cannam@86: For example, for an audio stream, it MAY contain the total number cannam@86: of PCM samples encoded after including all frames finished on this cannam@86: page. For a video stream it MAY contain the total number of video cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 10] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: frames encoded after this page. This is a hint for the decoder cannam@86: and gives it some timing and position information. Its meaning is cannam@86: dependent on the codec for that logical bitstream and specified in cannam@86: a specific media mapping. A special value of -1 (in two's cannam@86: complement) indicates that no packets finish on this page. cannam@86: cannam@86: 5. bitstream_serial_number: a 4 Byte field containing the unique cannam@86: serial number by which the logical bitstream is identified. cannam@86: cannam@86: 6. page_sequence_number: a 4 Byte field containing the sequence cannam@86: number of the page so the decoder can identify page loss. This cannam@86: sequence number is increasing on each logical bitstream cannam@86: separately. cannam@86: cannam@86: 7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of cannam@86: the page (including header with zero CRC field and page content). cannam@86: The generator polynomial is 0x04c11db7. cannam@86: cannam@86: 8. number_page_segments: 1 Byte giving the number of segment entries cannam@86: encoded in the segment table. cannam@86: cannam@86: 9. segment_table: number_page_segments Bytes containing the lacing cannam@86: values of all segments in this page. Each Byte contains one cannam@86: lacing value. cannam@86: cannam@86: The total header size in bytes is given by: cannam@86: header_size = number_page_segments + 27 [Byte] cannam@86: cannam@86: The total page size in Bytes is given by: cannam@86: page_size = header_size + sum(lacing_values: 1..number_page_segments) cannam@86: [Byte] cannam@86: cannam@86: 7. Security Considerations cannam@86: cannam@86: The Ogg encapsulation format is a container format and only cannam@86: encapsulates content (such as Vorbis-encoded audio). It does not cannam@86: provide for any generic encryption or signing of itself or its cannam@86: contained content bitstreams. However, it encapsulates any kind of cannam@86: content bitstream as long as there is a codec for it, and is thus cannam@86: able to contain encrypted and signed content data. It is also cannam@86: possible to add an external security mechanism that encrypts or signs cannam@86: an Ogg physical bitstream and thus provides content confidentiality cannam@86: and authenticity. cannam@86: cannam@86: As Ogg encapsulates binary data, it is possible to include executable cannam@86: content in an Ogg bitstream. This can be an issue with applications cannam@86: that are implemented using the Ogg format, especially when Ogg is cannam@86: used for streaming or file transfer in a networking scenario. As cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 11] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: such, Ogg does not pose a threat there. However, an application cannam@86: decoding Ogg and its encapsulated content bitstreams has to ensure cannam@86: correct handling of manipulated bitstreams, of buffer overflows and cannam@86: the like. cannam@86: cannam@86: 8. References cannam@86: cannam@86: [1] Walleij, L., "The application/ogg Media Type", RFC 3534, May cannam@86: 2003. cannam@86: cannam@86: [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement cannam@86: Levels", BCP 14, RFC 2119, March 1997. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 12] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: Appendix A. Glossary of terms and abbreviations cannam@86: cannam@86: bos page: The initial page (beginning of stream) of a logical cannam@86: bitstream which contains information to identify the codec type cannam@86: and other decoding-relevant information. cannam@86: cannam@86: chaining (or sequential multiplexing): Concatenation of two or more cannam@86: complete physical Ogg bitstreams. cannam@86: cannam@86: eos page: The final page (end of stream) of a logical bitstream. cannam@86: cannam@86: granule position: An increasing position number for a specific cannam@86: logical bitstream stored in the page header. Its meaning is cannam@86: dependent on the codec for that logical bitstream and specified in cannam@86: a specific media mapping. cannam@86: cannam@86: grouping (or concurrent multiplexing): Interleaving of pages of cannam@86: several logical bitstreams into one complete physical Ogg cannam@86: bitstream under the restriction that all bos pages of all grouped cannam@86: logical bitstreams MUST appear before any data pages. cannam@86: cannam@86: lacing value: An entry in the segment table of a page header cannam@86: representing the size of the related segment. cannam@86: cannam@86: logical bitstream: A sequence of bits being the result of an encoded cannam@86: media stream. cannam@86: cannam@86: media mapping: A specific use of the Ogg encapsulation format cannam@86: together with a specific (set of) codec(s). cannam@86: cannam@86: (Ogg) packet: A subpart of a logical bitstream that is created by the cannam@86: encoder for that bitstream and represents a meaningful entity for cannam@86: the encoder, but only a sequence of bits to the Ogg encapsulation. cannam@86: cannam@86: (Ogg) page: A physical bitstream consists of a sequence of Ogg pages cannam@86: containing data of one logical bitstream only. It usually cannam@86: contains a group of contiguous segments of one packet only, but cannam@86: sometimes packets are too large and need to be split over several cannam@86: pages. cannam@86: cannam@86: physical (Ogg) bitstream: The sequence of bits resulting from an Ogg cannam@86: encapsulation of one or several logical bitstreams. It consists cannam@86: of a sequence of pages from the logical bitstreams with the cannam@86: restriction that the pages of one logical bitstream MUST come in cannam@86: their correct temporal order. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 13] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: (Ogg) segment: The Ogg encapsulation process splits each packet into cannam@86: chunks of 255 bytes plus a last fractional chunk of less than 255 cannam@86: bytes. These chunks are called segments. cannam@86: cannam@86: Appendix B. Acknowledgements cannam@86: cannam@86: The author gratefully acknowledges the work that Christopher cannam@86: Montgomery and the Xiph.Org foundation have done in defining the Ogg cannam@86: multimedia project and as part of it the open file format described cannam@86: in this document. The author hopes that providing this document to cannam@86: the Internet community will help in promoting the Ogg multimedia cannam@86: project at http://www.xiph.org/. Many thanks also for the many cannam@86: technical and typo corrections that C. Montgomery and the Ogg cannam@86: community provided as feedback to this RFC. cannam@86: cannam@86: Author's Address cannam@86: cannam@86: Silvia Pfeiffer cannam@86: CSIRO, Australia cannam@86: Locked Bag 17 cannam@86: North Ryde, NSW 2113 cannam@86: Australia cannam@86: cannam@86: Phone: +61 2 9325 3141 cannam@86: EMail: Silvia.Pfeiffer@csiro.au cannam@86: URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/ cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 14] cannam@86: cannam@86: RFC 3533 OGG May 2003 cannam@86: cannam@86: cannam@86: Full Copyright Statement cannam@86: cannam@86: Copyright (C) The Internet Society (2003). All Rights Reserved. cannam@86: cannam@86: This document and translations of it may be copied and furnished to cannam@86: others, and derivative works that comment on or otherwise explain it cannam@86: or assist in its implementation may be prepared, copied, published cannam@86: and distributed, in whole or in part, without restriction of any cannam@86: kind, provided that the above copyright notice and this paragraph are cannam@86: included on all such copies and derivative works. However, this cannam@86: document itself may not be modified in any way, such as by removing cannam@86: the copyright notice or references to the Internet Society or other cannam@86: Internet organizations, except as needed for the purpose of cannam@86: developing Internet standards in which case the procedures for cannam@86: copyrights defined in the Internet Standards process must be cannam@86: followed, or as required to translate it into languages other than cannam@86: English. cannam@86: cannam@86: The limited permissions granted above are perpetual and will not be cannam@86: revoked by the Internet Society or its successors or assigns. cannam@86: cannam@86: This document and the information contained herein is provided on an cannam@86: "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING cannam@86: TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING cannam@86: BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION cannam@86: HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF cannam@86: MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. cannam@86: cannam@86: Acknowledgement cannam@86: cannam@86: Funding for the RFC Editor function is currently provided by the cannam@86: Internet Society. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Pfeiffer Informational [Page 15] cannam@86: