idnits 2.17.1 draft-pfeiffer-ogg-fileformat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '2' is mentioned on line 46, but not defined -- Looks like a reference, but probably isn't: 'Byte' on line 469 -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Pfeiffer 3 Internet-Draft Xiph.Org 4 Expires: May 2, 2003 November 2002 6 The Ogg encapsulation format version 0 7 draft-pfeiffer-ogg-fileformat-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on May 2, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document describes the Ogg bitstream format version 0, which is 39 a general, freely-available encapsulation format for media streams. 40 It is capable to encapsulate any kind and number of video and audio 41 encoding formats as well as other data streams in a single bitstream. 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [2]. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Requirements for a generic encapsulation format . . . . . . . 5 52 4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . . 6 53 5. The encapsulation process . . . . . . . . . . . . . . . . . . 9 54 6. The Ogg page format . . . . . . . . . . . . . . . . . . . . . 12 55 7. Security considerations . . . . . . . . . . . . . . . . . . . 15 56 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 58 A. Glossary of terms and abbreviations . . . . . . . . . . . . . 17 59 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 62 1. Introduction 64 The Ogg bitstream format has been developed as a part of a larger 65 project aimed at creating a set of components for the coding and 66 decoding of multimedia content (codecs) which are to be freely 67 available and freely re-implementable both in software and in 68 hardware for the computing community at large, including the Internet 69 community. It is the intention of the Ogg developers represented by 70 Xiph.Org that it be usable without intellectual property concerns. 72 This document describes the Ogg bitstream format and how to use it to 73 encapsulate one or several media bitstreams created by one or several 74 encoders. The Ogg transport bitstream is designed to provide 75 framing, error protection and seeking structure for higher-level 76 codec streams that consist of raw, unencapsulated data packets, such 77 as the Vorbis audio codec or the upcoming Tarkin and Theora video 78 codecs. It is capable to interleave different binary media and other 79 time-continuous data streams that are prepared by an encoder as a 80 sequence of data packets. Ogg provides enough information to 81 properly separate data back into such encoder created data packets at 82 the original packet boundaries without relying on decoding to find 83 packet boundaries. 85 Please note that there is a related document containing information 86 to register application/ogg as MIME type. It is currently being 87 processed as Internet-Draft: application/ogg MIME type I-D [1]. 89 2. Definitions 91 For describing the Ogg encapsulation process, a set of terms will be 92 used whose meaning needs to be well understood. Therefore, some of 93 the most fundamental terms are defined now before we start with the 94 description of the requirements for a generic media stream 95 encapsulation format, the process of encapsulation, and the concrete 96 format of the Ogg bitstream. See the Appendix for a more complete 97 glossary. 99 The result of an Ogg encapsulation is called the "Physical (Ogg) 100 Bitstream". It encapsulates one or several encoder-created 101 bitstreams, which are called "Logical Bitstreams". A logical 102 bitstream which is provided to the Ogg encapsulation process has a 103 structure, i.e. it is split up into a sequence of so-called 104 "Packets". The packets are created by the encoder of that logical 105 bitstream and represent meaningful entities for that encoder only 106 (e.g. an uncompressed stream may use video frames as packets). They 107 do not contain boundary information - strung together they appear to 108 be streams of random bytes with no landmarks. 110 Please note that the term "packet" is not used in this document to 111 signify entities for transport over a network. 113 3. Requirements for a generic encapsulation format 115 The design idea behind Ogg was to provide a generic, linear media 116 transport format to enable both file-based storage and stream-based 117 transmission of one or several interleaved media streams independent 118 of the encoding format of the media data. Such an encapsulation 119 format needs to provide: 121 o framing for logical bitstreams. 123 o interleaving of different logical bitstreams. 125 o detection of corruption. 127 o recapture after a parsing error. 129 o position landmarks for direct random access. 131 o streaming capability (i.e. no seeking is needed to build a 100% 132 complete bitstream). 134 o small overhead. 136 o simplicity to be fast. 138 o simple concatenation mechanism. 140 All of these design considerations have been taken into consideration 141 for Ogg. Ogg supports framing and interleaving of logical 142 bitstreams, seeking landmarks, detection of corruption, and stream 143 resynchronisation after a parsing error with no more than 144 approximately 1-2% overhead. It is a generic framework to perform 145 encapsulation of time-continuous bitstreams. It does not know any 146 specifics about the codec data that it encapsulates and is thus 147 independent of any media codec. 149 4. The Ogg bitstream format 151 A physical Ogg bitstream consists of multiple logical bitstreams 152 interleaved in so-called "Pages". Whole pages are taken in order 153 from multiple logical bitstreams multiplexed at the page level. The 154 logical bitstreams are identified by a unique serial number in the 155 header of each page of the physical bitstream. This unique serial 156 number is created randomly and does not have any connection to the 157 content or encoder of the logical bitstream it represents. Pages of 158 all logical bistreams are concurrently interleaved, but they need not 159 be in a regular order - they only require to be consecutive within 160 the logical bitstream. Ogg demultiplexing reconstructs the original 161 logical bitstreams from the physical bitstream by taking the pages in 162 order from the physical bitstream and redirecting them into the 163 appropriate logical decoding entity. 165 Each Ogg page contains only one type of data as it belongs to one 166 logical bitstream only. Pages are of variable size and have a page 167 header containing encapsulation and error recovery information. Each 168 logical bitstream in a physical Ogg bitstream starts with a special 169 start page (bos=beginning of stream) and ends with a special page 170 (eos=end of stream). The bos page contains information to identify 171 the codec type and any additional information to set up the decoding 172 process. The format of that page is therefore dependent on the codec 173 and therefore MUST be given in the encoding specification of that 174 logical bitstream type. An example for such a media mapping is "Ogg 175 Vorbis", which provides the name and revision of the Vorbis codec, 176 the audio rate and the audio quality on the Ogg Vorbis bos page. 178 Ogg knows two types of multiplexing: concurrent multiplexing (so- 179 called "Grouping") and sequential multiplexing (so-called 180 "Chaining"). Grouping defines how to interleave several logical 181 bitstreams page-wise in the same physical bitstream. Grouping is for 182 example needed for interleaving a video stream with several 183 synchronised audio tracks using different codecs in different logical 184 bitstreams. Chaining on the other hand is defined to provide a 185 simple mechanism to concatenate physical Ogg bitstreams as is often 186 needed for streaming applications. 188 In grouping, all bos pages of all logical bitstreams MUST appear 189 together at the beginning of the Ogg bitstream. The media mapping 190 specifies the order of the initial pages. For example, grouping of a 191 specific Ogg video and Ogg audio bitstream may specify that the 192 physical bitstream MUST begin with the bos page of the logical video 193 bitstream followed by the bos page of the audio bitstream. Unlike 194 bos pages eos pages for the logical bitstreams need not all occur 195 contiguously. Eos pages may be 'nil' pages, that is, pages 196 containing no content but simply a page header with position 197 information and the eos flag set in the page header. Each grouped 198 logical bitstream MUST have a unique serial number within the scope 199 of the physical bitstream. 201 In chaining, complete logical bitstreams are concatenated. The 202 bitstreams do not overlap, i.e. the eos page of a given logical 203 bistream is immediately followed by the bos page of the next. Each 204 chained logical bitstream MUST have a unique serial number within the 205 scope of the physical bitstream. 207 It is possible to consecutively chain groups of concurrently 208 multiplexed bitstreams. The groups, when unchained, MUST stand on 209 their own as a valid concurrently multiplexed bitstream. The 210 following diagram shows a schematic example of such a physical 211 bitstream that obeys all the rules of both grouped and chained 212 multiplexed bitstreams. 214 physical bitstream with pages of 215 different logical bitstreams grouped and chained 216 ------------------------------------------------------------- 217 |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#| 218 ------------------------------------------------------------- 219 bos bos bos eos eos eos bos eos 221 In this example, there are two chained physical bitstreams, the first 222 of which is a grouped stream of three logical bitstreams A, B, and C. 223 The second physical bitstream is chained after the end of the grouped 224 bitstream, which ends after the last eos page of all its grouped 225 logical bitstreams. As can be seen, grouped bitstreams begin 226 together - all of the eos pages MUST appear before any data pages. 227 It can also be seen that pages of concurrently multiplexed bitstreams 228 need not conform to a regular order. And it can be seen that a 229 grouped bitstream can end long before the other bitstreams in the 230 group end. 232 Ogg does not know any specifics about the codec data except that each 233 logical bitstream belongs to a different codec, the data from the 234 codec comes in order and has position markers (so-called "Granule 235 positions"). Ogg does not have a concept of 'time': it only knows 236 about sequentially increasing, unitless position markers. An 237 application can only get temporal information through higher layers 238 which have access to the codec APIs to assign and convert granule 239 positions or time. 241 A specific definition of a media mapping using Ogg may put further 242 constraints on its specific use of the Ogg bitstream format. For 243 example, a specific media mapping may require that all the eos pages 244 for all grouped bitstreams need to appear in direct sequence. An 245 example for a media mapping is the specification of "Ogg Vorbis" 246 which uses the Ogg framework to encapsulate Vorbis-encoded audio data 247 for stream-based storage (such as files) and transport (such as TCP 248 streams or pipes). Ogg Vorbis puts a further constraint onto Ogg by 249 specifying that concurrent multiplexing is not allowed in Ogg Vorbis 250 files. Another example is the upcoming Ogg Theora specification. 251 Ogg Theora encapsulates a Vorbis-encoded audio bitstream and a 252 Tarkin-encoded video bitstream in a single physical Ogg bitstream. 253 As Ogg does not specify temporal relationships between the 254 encapsulated concurrently multiplexed bitstreams, the temporal 255 synchronisation between the audio and video stream will be specified 256 in this media mapping. 258 5. The encapsulation process 260 The process of multiplexing different logical bitstreams happens at 261 the level of pages as described above. The bitstreams provided by 262 encoders are however handed over to Ogg as so-called "Packets" with 263 packet boundaries dependent on the encoding format. The process of 264 encapsulating packets into pages will be described now. 266 From Ogg's perspective, packets can be of any arbitrary size. A 267 specific media mapping will define how to group or break up packets 268 from a specific media encoder. A nominal page size of approximately 269 4-8 kByte is RECOMMENDED for latency reasons. As Ogg pages have a 270 maximum size of about 64 kByte, sometimes a packet has to be 271 distributed over several pages. To simplify that process, Ogg 272 divides each packet into 255 byte long chunks plus a final usually 273 shorter chunk. These chunks are called "Ogg Segments". They are 274 only a logical construct and do not have a header for themselves. 276 A group of contiguous segments is wrapped into a variable length page 277 preceeded by a header. A segment table in the page header tells 278 about the "Lacing values" (sizes) of the segments included in the 279 page. A flag in the page header tells whether a page contains a 280 packet continued from a previous page. Note that a lacing value of 281 255 implies that a second lacing value follows in the packet, and a 282 value of less than 255 marks the end of the packet after that many 283 additional bytes. A packet of 255 bytes (or a multiple of 255 bytes) 284 is terminated by a lacing value of 0. Note also that a 'nil' (zero 285 length) packet is not an error; it consists of nothing more than a 286 lacing value of zero in the header. 288 The encoding is optimised for speed and the expected case of the 289 majority of packets being between 50 and 200 bytes large. This is a 290 design justification rather than a recommendation. This encoding 291 both avoids imposing a maximum packet size as well as imposing 292 minimum overhead on small packets. In contrast, e.g. simply using 293 two bytes at the head of every packet and having a max packet size of 294 32 kBytes would always penalize small packets (< 255 bytes, the 295 typical case) with twice the segmentation overhead. Using the lacing 296 values as suggested, small packets see the minimum possible byte- 297 aligned overhead (1 byte) and large packets (>512 bytes) see a fairly 298 constant ~0.5% overhead on encoding space. 300 The following diagram shows a schematic example of a media mapping 301 using Ogg and grouped logical bitstreams: 303 logical bitstream with packet boundaries 304 ----------------------------------------------------------------- 305 > | packet_1 | packet_2 | packet_3 | < 306 ----------------------------------------------------------------- 308 |segmentation (logically only) 309 v 311 packet_1 (5 segments) packet_2 (4 segs) p_3 (2 segs) 312 ------------------------------ -------------------- ------------ 313 .. |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | .. 314 ------------------------------ -------------------- ------------ 316 | page encapsulation 317 v 319 page_1 (packet_1 data) page_2 (pket_1 data) page_3 (packet_2 data) 320 ------------------------ ---------------- ------------------------ 321 |H|------------------- | |H|----------- | |H|------------------- | 322 |D||seg_1|seg_2|seg_3| | |D|seg_4|s_5 | | |D||seg_1|seg_2|seg_3| | ... 323 |R|------------------- | |R|----------- | |R|------------------- | 324 ------------------------ ---------------- ------------------------ 326 | 327 pages of | 328 other --------| | 329 logical ------- 330 bitstreams | MUX | 331 ------- 332 | 333 v 335 page_1 page_2 page_3 336 ------ ------ ------- ----- ------- 337 ... || | || | || | || | || | ... 338 ------ ------ ------- ----- ------- 339 physical Ogg bitstream 341 In this example we take a snapshot of the encapsulation process of 342 one logical bitstream. We can see part of that bitstream's 343 subdivision into packets as provided by the codec. The Ogg 344 encapsulation process chops up the packets into segments. The 345 packets in this example are rather large such that packet_1 is split 346 into 5 segments - 4 segments with 255 bytes and a final smaller one. 347 Packet_2 is split into 4 segments - 3 segments with 255 bytes and a 348 final very small one - and packet_3 is split into two segments. The 349 encapsulation process then creates pages, which are quite small in 350 this example. Page_1 consists of the first three segments of 351 packet_1, page_2 contains the remaining 2 segments from packet_1, and 352 page_3 contains the first three pages of packet_2. Finally, this 353 logical bitstream is multiplexed into a physical Ogg bitstream with 354 pages of other logical bitstreams. 356 6. The Ogg page format 358 A physical Ogg bitstream consists of a sequence of concatenated 359 pages. Pages are of variable size, usually 4-8 kB, maximum 65307 360 bytes. A page header contains all the information needed to 361 demultiplex the logical bitstreams out of the physical bitstream and 362 to perform basic error recovery and landmarks for seeking. Each page 363 is a self-contained entity such that the page decode mechanism can 364 recognize, verify, and handle single pages at a time without 365 requiring the overall bitstream. 367 The Ogg page header has the following format: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | capture_pattern: Magic number for page start "OggS" | 0-3 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | version | header_type | granule_position | 4-7 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 8-11 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | bitstream_serial_number | 12-15 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | page_sequence_number | 16-19 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | CRC_checksum | 20-23 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | |page_segments | segment_table | 24-27 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | ... | 28- 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 The LSb (least significant bit) comes first in the Bytes. Fields 390 with more than one byte length are encoded LSB (least significant 391 byte) first. 393 The fields in the page header have the following meaning: 395 1. capture_pattern: a 4 Byte field that signifies the beginning of a 396 page. It contains the magic numbers: 398 0x4f 'O' 400 0x67 'g' 402 0x67 'g' 403 0x53 'S' 405 It helps a decoder to find the page boundaries and regain 406 synchronisation after parsing a corrupted stream. Once the 407 capture pattern is found, the decoder verifies page sync and 408 integrity by computing and comparing the checksum. 410 2. stream_structure_version: 1 Byte signifying the version number of 411 the Ogg file format used in this stream (this document specifies 412 version 0). 414 3. header_type_flag: the bits in this 1 Byte field identify the 415 specific type of this page. 417 * bit 0x01 419 set: page contains data of a media frame continued from the 420 previous page 422 unset: page contains a fresh media frame 424 * bit 0x02 426 set: this is the first page of a logical bitstream (bos) 428 unset: this page is not a first page 430 * bit 0x04 432 set: this is the last page of a logical bitstream (eos) 434 unset: this page is not a last page 436 4. granule_position: a 8 Byte field containing position information. 437 For example, for an audio stream it contains the total number of 438 PCM samples encoded after including all frames finished on this 439 page. For a video stream it contains the total number of video 440 frames encoded after this page. This is a hint for the decoder 441 and gives it some timing and position information. It's meaning 442 is dependent on the codec for that logical bitstream and 443 specified in a specific media mapping. 445 5. bitstream_serial_number: a 4 Byte field containing the serial 446 number by which the logical bitstream is identified. 448 6. page_sequence_number: a 4 Byte field containing the sequence 449 number of the page so the decoder can identify page loss. This 450 sequence number is increasing on each logical bitstream 451 separately. 453 7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of 454 the page (including header with zero CRC field and page content). 455 The generator polynomial is 0x04c11db7. 457 8. number_page_segments: 1 Byte giving the number of segment entries 458 encoded in the segment table. 460 9. segment_table: number_page_segments Bytes containing the lacing 461 values of all segments in this page. Each Byte contains one 462 lacing value. 464 The total header size in bytes is given by: 465 header_size = number_page_segments + 27 [Byte] 467 The total page size in Bytes is given by: 468 page_size = header_size + sum(lacing_values: 1..number_page_segments) 469 [Byte] 471 7. Security considerations 473 The Ogg encapsulation format is a container format and only 474 encapsulates content (such as Vorbis-encoded audio). It does not 475 provide for any generic encryption or signing of itself or its 476 contained content bitstreams. It however encapsulates any kind of 477 content bitstream as long as there is a codec for it, and is thus 478 capable to contain encrypted and signed content data. It is also 479 possible to add an external security mechanism that encrypts or signs 480 an Ogg physical bistream and thus provides content confidentiality 481 and authenticity. 483 As Ogg enapsulates binary data, it is possible to include executable 484 content in an Ogg bitstream. This can be an issue with applications 485 that are implemented using the Ogg format, especially when Ogg is 486 used for streaming or file transfer in a networking scenario. Ogg as 487 such does not pose a threat there. However, an application decoding 488 Ogg and its encapsulated content bitstreams has to ensure correct 489 handling of manipulated bitstreams, of buffer overflows and the like. 491 References 493 [1] Walleij, L., "Internet-Draft: The application/ogg Media Type", 494 Internet-Draft XXXX, May 2002. 496 Author's Address 498 Silvia Pfeiffer 499 For Xiph.Org 501 EMail: Silvia.Pfeiffer@csiro.au 503 Appendix A. Glossary of terms and abbreviations 505 bos page: The initial page (beginning of stream) of a logical 506 bitstream which contains information to identify the codec type 507 and other decoding-relevant information. 509 chaining (or sequential multiplexing): Concatenation of two or more 510 complete physical Ogg bitstreams. 512 eos page: The final page (end of stream) of a logical bitstream. 514 granule position: An increasing position number for a specific 515 logical bitstream stored in the page header. It's meaning is 516 dependent on the codec for that logical bitstream and specified in 517 a specific media mapping. 519 grouping (or concurrent multiplexing): Interleaving of pages of 520 several logical bitstreams into one complete physical Ogg bistream 521 under the restriction that all bos pages of all grouped logical 522 bitstreams MUST appear before any data pages. 524 lacing value: An entry in the segment table of a page header 525 representing the size of the related segment. 527 logical bistream: A sequence of bits being the result of an encoded 528 media stream. 530 media mapping: A specific use of the Ogg encapsulation format 531 together with a specific (set of) codec(s). 533 (Ogg) packet: A subpart of a logical bitstream that is created by the 534 encoder for that bitstream and represents a meaningful entity for 535 the encoder, but only a sequence of bits to the Ogg encapsulation. 537 (Ogg) page: A physical bitstream consists of a sequence of Ogg pages 538 containing data of one logical bitstream only. It usually 539 contains a group of contiguous segments of one packet only, but 540 sometimes packets are too large and need to be split over several 541 pages. 543 physical (Ogg) bitstream: The sequence of bits resulting from an Ogg 544 encapsulation of one or several logical bitstreams. It consists 545 of a sequence of pages from the logical bitstreams with the 546 restriction that the pages of one logical bitstream MUST come in 547 their correct temporal order. 549 (Ogg) segment: The Ogg encapsulation process splits each packet into 550 chunks of 255 bytes plus a last fractional chunk of less than 255 551 bytes. These chunks are called segments. 553 Appendix B. Acknowledgements 555 The author gratefully acknowledges the work that Monty and the 556 Xiph.Org foundation (also known as Xiphophorus) have done in defining 557 the Ogg multimedia project and as part of it the open file format 558 described in this document. The author hopes that providing this 559 document to the Internet community will help in promoting the Ogg 560 multimedia project at http://www.xiph.org/. 562 Full Copyright Statement 564 Copyright (C) The Internet Society (2002). All Rights Reserved. 566 This document and translations of it may be copied and furnished to 567 others, and derivative works that comment on or otherwise explain it 568 or assist in its implementation may be prepared, copied, published 569 and distributed, in whole or in part, without restriction of any 570 kind, provided that the above copyright notice and this paragraph are 571 included on all such copies and derivative works. However, this 572 document itself may not be modified in any way, such as by removing 573 the copyright notice or references to the Internet Society or other 574 Internet organizations, except as needed for the purpose of 575 developing Internet standards in which case the procedures for 576 copyrights defined in the Internet Standards process must be 577 followed, or as required to translate it into languages other than 578 English. 580 The limited permissions granted above are perpetual and will not be 581 revoked by the Internet Society or its successors or assigns. 583 This document and the information contained herein is provided on an 584 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 585 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 586 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 587 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 588 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 590 Acknowledgement 592 Funding for the RFC Editor function is currently provided by the 593 Internet Society.