1 2 3 4 5 6 7 Network Working Group S. Pfeiffer 8 Request for Comments: 3533 CSIRO 9 Category: Informational May 2003 10 11 12 The Ogg Encapsulation Format Version 0 13 14 Status of this Memo 15 16 This memo provides information for the Internet community. It does 17 not specify an Internet standard of any kind. Distribution of this 18 memo is unlimited. 19 20 Copyright Notice 21 22 Copyright (C) The Internet Society (2003). All Rights Reserved. 23 24 Abstract 25 26 This document describes the Ogg bitstream format version 0, which is 27 a general, freely-available encapsulation format for media streams. 28 It is able to encapsulate any kind and number of video and audio 29 encoding formats as well as other data streams in a single bitstream. 30 31 Terminology 32 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in BCP 14, RFC 2119 [2]. 36 37 Table of Contents 38 39 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 41 3. Requirements for a generic encapsulation format . . . . . . . 3 42 4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . . 3 43 5. The encapsulation process . . . . . . . . . . . . . . . . . . 6 44 6. The Ogg page format . . . . . . . . . . . . . . . . . . . . . 9 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 46 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 47 A. Glossary of terms and abbreviations . . . . . . . . . . . . . 13 48 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 50 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 51 52 53 54 55 56 57 58 Pfeiffer Informational [Page 1] 59 61 RFC 3533 OGG May 2003 62 63 64 1. Introduction 65 66 The Ogg bitstream format has been developed as a part of a larger 67 project aimed at creating a set of components for the coding and 68 decoding of multimedia content (codecs) which are to be freely 69 available and freely re-implementable, both in software and in 70 hardware for the computing community at large, including the Internet 71 community. It is the intention of the Ogg developers represented by 72 Xiph.Org that it be usable without intellectual property concerns. 73 74 This document describes the Ogg bitstream format and how to use it to 75 encapsulate one or several media bitstreams created by one or several 76 encoders. The Ogg transport bitstream is designed to provide 77 framing, error protection and seeking structure for higher-level 78 codec streams that consist of raw, unencapsulated data packets, such 79 as the Vorbis audio codec or the upcoming Tarkin and Theora video 80 codecs. It is capable of interleaving different binary media and 81 other time-continuous data streams that are prepared by an encoder as 82 a sequence of data packets. Ogg provides enough information to 83 properly separate data back into such encoder created data packets at 84 the original packet boundaries without relying on decoding to find 85 packet boundaries. 86 87 Please note that the MIME type application/ogg has been registered 88 with the IANA [1]. 89 90 2. Definitions 91 92 For describing the Ogg encapsulation process, a set of terms will be 93 used whose meaning needs to be well understood. Therefore, some of 94 the most fundamental terms are defined now before we start with the 95 description of the requirements for a generic media stream 96 encapsulation format, the process of encapsulation, and the concrete 97 format of the Ogg bitstream. See the Appendix for a more complete 98 glossary. 99 100 The result of an Ogg encapsulation is called the "Physical (Ogg) 101 Bitstream". It encapsulates one or several encoder-created 102 bitstreams, which are called "Logical Bitstreams". A logical 103 bitstream, provided to the Ogg encapsulation process, has a 104 structure, i.e., it is split up into a sequence of so-called 105 "Packets". The packets are created by the encoder of that logical 106 bitstream and represent meaningful entities for that encoder only 107 (e.g., an uncompressed stream may use video frames as packets). They 108 do not contain boundary information - strung together they appear to 109 be streams of random bytes with no landmarks. 110 111 112 113 114 115 Pfeiffer Informational [Page 2] 116 118 RFC 3533 OGG May 2003 119 120 121 Please note that the term "packet" is not used in this document to 122 signify entities for transport over a network. 123 124 3. Requirements for a generic encapsulation format 125 126 The design idea behind Ogg was to provide a generic, linear media 127 transport format to enable both file-based storage and stream-based 128 transmission of one or several interleaved media streams independent 129 of the encoding format of the media data. Such an encapsulation 130 format needs to provide: 131 132 o framing for logical bitstreams. 133 134 o interleaving of different logical bitstreams. 135 136 o detection of corruption. 137 138 o recapture after a parsing error. 139 140 o position landmarks for direct random access of arbitrary positions 141 in the bitstream. 142 143 o streaming capability (i.e., no seeking is needed to build a 100% 144 complete bitstream). 145 146 o small overhead (i.e., use no more than approximately 1-2% of 147 bitstream bandwidth for packet boundary marking, high-level 148 framing, sync and seeking). 149 150 o simplicity to enable fast parsing. 151 152 o simple concatenation mechanism of several physical bitstreams. 153 154 All of these design considerations have been taken into consideration 155 for Ogg. Ogg supports framing and interleaving of logical 156 bitstreams, seeking landmarks, detection of corruption, and stream 157 resynchronisation after a parsing error with no more than 158 approximately 1-2% overhead. It is a generic framework to perform 159 encapsulation of time-continuous bitstreams. It does not know any 160 specifics about the codec data that it encapsulates and is thus 161 independent of any media codec. 162 163 4. The Ogg bitstream format 164 165 A physical Ogg bitstream consists of multiple logical bitstreams 166 interleaved in so-called "Pages". Whole pages are taken in order 167 from multiple logical bitstreams multiplexed at the page level. The 168 logical bitstreams are identified by a unique serial number in the 169 170 171 172 Pfeiffer Informational [Page 3] 173 175 RFC 3533 OGG May 2003 176 177 178 header of each page of the physical bitstream. This unique serial 179 number is created randomly and does not have any connection to the 180 content or encoder of the logical bitstream it represents. Pages of 181 all logical bitstreams are concurrently interleaved, but they need 182 not be in a regular order - they are only required to be consecutive 183 within the logical bitstream. Ogg demultiplexing reconstructs the 184 original logical bitstreams from the physical bitstream by taking the 185 pages in order from the physical bitstream and redirecting them into 186 the appropriate logical decoding entity. 187 188 Each Ogg page contains only one type of data as it belongs to one 189 logical bitstream only. Pages are of variable size and have a page 190 header containing encapsulation and error recovery information. Each 191 logical bitstream in a physical Ogg bitstream starts with a special 192 start page (bos=beginning of stream) and ends with a special page 193 (eos=end of stream). 194 195 The bos page contains information to uniquely identify the codec type 196 and MAY contain information to set up the decoding process. The bos 197 page SHOULD also contain information about the encoded media - for 198 example, for audio, it should contain the sample rate and number of 199 channels. By convention, the first bytes of the bos page contain 200 magic data that uniquely identifies the required codec. It is the 201 responsibility of anyone fielding a new codec to make sure it is 202 possible to reliably distinguish his/her codec from all other codecs 203 in use. There is no fixed way to detect the end of the codec- 204 identifying marker. The format of the bos page is dependent on the 205 codec and therefore MUST be given in the encapsulation specification 206 of that logical bitstream type. Ogg also allows but does not require 207 secondary header packets after the bos page for logical bitstreams 208 and these must also precede any data packets in any logical 209 bitstream. These subsequent header packets are framed into an 210 integral number of pages, which will not contain any data packets. 211 So, a physical bitstream begins with the bos pages of all logical 212 bitstreams containing one initial header packet per page, followed by 213 the subsidiary header packets of all streams, followed by pages 214 containing data packets. 215 216 The encapsulation specification for one or more logical bitstreams is 217 called a "media mapping". An example for a media mapping is "Ogg 218 Vorbis", which uses the Ogg framework to encapsulate Vorbis-encoded 219 audio data for stream-based storage (such as files) and transport 220 (such as TCP streams or pipes). Ogg Vorbis provides the name and 221 revision of the Vorbis codec, the audio rate and the audio quality on 222 the Ogg Vorbis bos page. It also uses two additional header pages 223 per logical bitstream. The Ogg Vorbis bos page starts with the byte 224 0x01, followed by "vorbis" (a total of 7 bytes of identifier). 225 226 227 228 229 Pfeiffer Informational [Page 4] 230 232 RFC 3533 OGG May 2003 233 234 235 Ogg knows two types of multiplexing: concurrent multiplexing (so- 236 called "Grouping") and sequential multiplexing (so-called 237 "Chaining"). Grouping defines how to interleave several logical 238 bitstreams page-wise in the same physical bitstream. Grouping is for 239 example needed for interleaving a video stream with several 240 synchronised audio tracks using different codecs in different logical 241 bitstreams. Chaining on the other hand, is defined to provide a 242 simple mechanism to concatenate physical Ogg bitstreams, as is often 243 needed for streaming applications. 244 245 In grouping, all bos pages of all logical bitstreams MUST appear 246 together at the beginning of the Ogg bitstream. The media mapping 247 specifies the order of the initial pages. For example, the grouping 248 of a specific Ogg video and Ogg audio bitstream may specify that the 249 physical bitstream MUST begin with the bos page of the logical video 250 bitstream, followed by the bos page of the audio bitstream. Unlike 251 bos pages, eos pages for the logical bitstreams need not all occur 252 contiguously. Eos pages may be 'nil' pages, that is, pages 253 containing no content but simply a page header with position 254 information and the eos flag set in the page header. Each grouped 255 logical bitstream MUST have a unique serial number within the scope 256 of the physical bitstream. 257 258 In chaining, complete logical bitstreams are concatenated. The 259 bitstreams do not overlap, i.e., the eos page of a given logical 260 bitstream is immediately followed by the bos page of the next. Each 261 chained logical bitstream MUST have a unique serial number within the 262 scope of the physical bitstream. 263 264 It is possible to consecutively chain groups of concurrently 265 multiplexed bitstreams. The groups, when unchained, MUST stand on 266 their own as a valid concurrently multiplexed bitstream. The 267 following diagram shows a schematic example of such a physical 268 bitstream that obeys all the rules of both grouped and chained 269 multiplexed bitstreams. 270 271 physical bitstream with pages of 272 different logical bitstreams grouped and chained 273 ------------------------------------------------------------- 274 |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#| 275 ------------------------------------------------------------- 276 bos bos bos eos eos eos bos eos 277 278 In this example, there are two chained physical bitstreams, the first 279 of which is a grouped stream of three logical bitstreams A, B, and C. 280 The second physical bitstream is chained after the end of the grouped 281 bitstream, which ends after the last eos page of all its grouped 282 logical bitstreams. As can be seen, grouped bitstreams begin 283 284 285 286 Pfeiffer Informational [Page 5] 287 289 RFC 3533 OGG May 2003 290 291 292 together - all of the bos pages MUST appear before any data pages. 293 It can also be seen that pages of concurrently multiplexed bitstreams 294 need not conform to a regular order. And it can be seen that a 295 grouped bitstream can end long before the other bitstreams in the 296 group end. 297 298 Ogg does not know any specifics about the codec data except that each 299 logical bitstream belongs to a different codec, the data from the 300 codec comes in order and has position markers (so-called "Granule 301 positions"). Ogg does not have a concept of 'time': it only knows 302 about sequentially increasing, unitless position markers. An 303 application can only get temporal information through higher layers 304 which have access to the codec APIs to assign and convert granule 305 positions or time. 306 307 A specific definition of a media mapping using Ogg may put further 308 constraints on its specific use of the Ogg bitstream format. For 309 example, a specific media mapping may require that all the eos pages 310 for all grouped bitstreams need to appear in direct sequence. An 311 example for a media mapping is the specification of "Ogg Vorbis". 312 Another example is the upcoming "Ogg Theora" specification which 313 encapsulates Theora-encoded video data and usually comes multiplexed 314 with a Vorbis stream for an Ogg containing synchronised audio and 315 video. As Ogg does not specify temporal relationships between the 316 encapsulated concurrently multiplexed bitstreams, the temporal 317 synchronisation between the audio and video stream will be specified 318 in this media mapping. To enable streaming, pages from various 319 logical bitstreams will typically be interleaved in chronological 320 order. 321 322 5. The encapsulation process 323 324 The process of multiplexing different logical bitstreams happens at 325 the level of pages as described above. The bitstreams provided by 326 encoders are however handed over to Ogg as so-called "Packets" with 327 packet boundaries dependent on the encoding format. The process of 328 encapsulating packets into pages will be described now. 329 330 From Ogg's perspective, packets can be of any arbitrary size. A 331 specific media mapping will define how to group or break up packets 332 from a specific media encoder. As Ogg pages have a maximum size of 333 about 64 kBytes, sometimes a packet has to be distributed over 334 several pages. To simplify that process, Ogg divides each packet 335 into 255 byte long chunks plus a final shorter chunk. These chunks 336 are called "Ogg Segments". They are only a logical construct and do 337 not have a header for themselves. 338 339 340 341 342 343 Pfeiffer Informational [Page 6] 344 346 RFC 3533 OGG May 2003 347 348 349 A group of contiguous segments is wrapped into a variable length page 350 preceded by a header. A segment table in the page header tells about 351 the "Lacing values" (sizes) of the segments included in the page. A 352 flag in the page header tells whether a page contains a packet 353 continued from a previous page. Note that a lacing value of 255 354 implies that a second lacing value follows in the packet, and a value 355 of less than 255 marks the end of the packet after that many 356 additional bytes. A packet of 255 bytes (or a multiple of 255 bytes) 357 is terminated by a lacing value of 0. Note also that a 'nil' (zero 358 length) packet is not an error; it consists of nothing more than a 359 lacing value of zero in the header. 360 361 The encoding is optimized for speed and the expected case of the 362 majority of packets being between 50 and 200 bytes large. This is a 363 design justification rather than a recommendation. This encoding 364 both avoids imposing a maximum packet size as well as imposing 365 minimum overhead on small packets. In contrast, e.g., simply using 366 two bytes at the head of every packet and having a max packet size of 367 32 kBytes would always penalize small packets (< 255 bytes, the 368 typical case) with twice the segmentation overhead. Using the lacing 369 values as suggested, small packets see the minimum possible byte- 370 aligned overhead (1 byte) and large packets (>512 bytes) see a fairly 371 constant ~0.5% overhead on encoding space. 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 Pfeiffer Informational [Page 7] 401 403 RFC 3533 OGG May 2003 404 405 406 The following diagram shows a schematic example of a media mapping 407 using Ogg and grouped logical bitstreams: 408 409 logical bitstream with packet boundaries 410 ----------------------------------------------------------------- 411 > | packet_1 | packet_2 | packet_3 | < 412 ----------------------------------------------------------------- 413 414 |segmentation (logically only) 415 v 416 417 packet_1 (5 segments) packet_2 (4 segs) p_3 (2 segs) 418 ------------------------------ -------------------- ------------ 419 .. |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | .. 420 ------------------------------ -------------------- ------------ 421 422 | page encapsulation 423 v 424 425 page_1 (packet_1 data) page_2 (pket_1 data) page_3 (packet_2 data) 426 ------------------------ ---------------- ------------------------ 427 |H|------------------- | |H|----------- | |H|------------------- | 428 |D||seg_1|seg_2|seg_3| | |D|seg_4|s_5 | | |D||seg_1|seg_2|seg_3| | ... 429 |R|------------------- | |R|----------- | |R|------------------- | 430 ------------------------ ---------------- ------------------------ 431 432 | 433 pages of | 434 other --------| | 435 logical ------- 436 bitstreams | MUX | 437 ------- 438 | 439 v 440 441 page_1 page_2 page_3 442 ------ ------ ------- ----- ------- 443 ... || | || | || | || | || | ... 444 ------ ------ ------- ----- ------- 445 physical Ogg bitstream 446 447 In this example we take a snapshot of the encapsulation process of 448 one logical bitstream. We can see part of that bitstream's 449 subdivision into packets as provided by the codec. The Ogg 450 encapsulation process chops up the packets into segments. The 451 packets in this example are rather large such that packet_1 is split 452 into 5 segments - 4 segments with 255 bytes and a final smaller one. 453 Packet_2 is split into 4 segments - 3 segments with 255 bytes and a 454 455 456 457 Pfeiffer Informational [Page 8] 458 460 RFC 3533 OGG May 2003 461 462 463 final very small one - and packet_3 is split into two segments. The 464 encapsulation process then creates pages, which are quite small in 465 this example. Page_1 consists of the first three segments of 466 packet_1, page_2 contains the remaining 2 segments from packet_1, and 467 page_3 contains the first three pages of packet_2. Finally, this 468 logical bitstream is multiplexed into a physical Ogg bitstream with 469 pages of other logical bitstreams. 470 471 6. The Ogg page format 472 473 A physical Ogg bitstream consists of a sequence of concatenated 474 pages. Pages are of variable size, usually 4-8 kB, maximum 65307 475 bytes. A page header contains all the information needed to 476 demultiplex the logical bitstreams out of the physical bitstream and 477 to perform basic error recovery and landmarks for seeking. Each page 478 is a self-contained entity such that the page decode mechanism can 479 recognize, verify, and handle single pages at a time without 480 requiring the overall bitstream. 481 482 The Ogg page header has the following format: 483 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | capture_pattern: Magic number for page start "OggS" | 0-3 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | version | header_type | granule_position | 4-7 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 8-11 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | bitstream_serial_number | 12-15 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | page_sequence_number | 16-19 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | CRC_checksum | 20-23 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | |page_segments | segment_table | 24-27 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | ... | 28- 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 504 The LSb (least significant bit) comes first in the Bytes. Fields 505 with more than one byte length are encoded LSB (least significant 506 byte) first. 507 508 509 510 511 512 513 514 Pfeiffer Informational [Page 9] 515 517 RFC 3533 OGG May 2003 518 519 520 The fields in the page header have the following meaning: 521 522 1. capture_pattern: a 4 Byte field that signifies the beginning of a 523 page. It contains the magic numbers: 524 525 0x4f 'O' 526 527 0x67 'g' 528 529 0x67 'g' 530 531 0x53 'S' 532 533 It helps a decoder to find the page boundaries and regain 534 synchronisation after parsing a corrupted stream. Once the 535 capture pattern is found, the decoder verifies page sync and 536 integrity by computing and comparing the checksum. 537 538 2. stream_structure_version: 1 Byte signifying the version number of 539 the Ogg file format used in this stream (this document specifies 540 version 0). 541 542 3. header_type_flag: the bits in this 1 Byte field identify the 543 specific type of this page. 544 545 * bit 0x01 546 547 set: page contains data of a packet continued from the previous 548 page 549 550 unset: page contains a fresh packet 551 552 * bit 0x02 553 554 set: this is the first page of a logical bitstream (bos) 555 556 unset: this page is not a first page 557 558 * bit 0x04 559 560 set: this is the last page of a logical bitstream (eos) 561 562 unset: this page is not a last page 563 564 4. granule_position: an 8 Byte field containing position information. 565 For example, for an audio stream, it MAY contain the total number 566 of PCM samples encoded after including all frames finished on this 567 page. For a video stream it MAY contain the total number of video 568 569 570 571 Pfeiffer Informational [Page 10] 572 574 RFC 3533 OGG May 2003 575 576 577 frames encoded after this page. This is a hint for the decoder 578 and gives it some timing and position information. Its meaning is 579 dependent on the codec for that logical bitstream and specified in 580 a specific media mapping. A special value of -1 (in two's 581 complement) indicates that no packets finish on this page. 582 583 5. bitstream_serial_number: a 4 Byte field containing the unique 584 serial number by which the logical bitstream is identified. 585 586 6. page_sequence_number: a 4 Byte field containing the sequence 587 number of the page so the decoder can identify page loss. This 588 sequence number is increasing on each logical bitstream 589 separately. 590 591 7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of 592 the page (including header with zero CRC field and page content). 593 The generator polynomial is 0x04c11db7. 594 595 8. number_page_segments: 1 Byte giving the number of segment entries 596 encoded in the segment table. 597 598 9. segment_table: number_page_segments Bytes containing the lacing 599 values of all segments in this page. Each Byte contains one 600 lacing value. 601 602 The total header size in bytes is given by: 603 header_size = number_page_segments + 27 [Byte] 604 605 The total page size in Bytes is given by: 606 page_size = header_size + sum(lacing_values: 1..number_page_segments) 607 [Byte] 608 609 7. Security Considerations 610 611 The Ogg encapsulation format is a container format and only 612 encapsulates content (such as Vorbis-encoded audio). It does not 613 provide for any generic encryption or signing of itself or its 614 contained content bitstreams. However, it encapsulates any kind of 615 content bitstream as long as there is a codec for it, and is thus 616 able to contain encrypted and signed content data. It is also 617 possible to add an external security mechanism that encrypts or signs 618 an Ogg physical bitstream and thus provides content confidentiality 619 and authenticity. 620 621 As Ogg encapsulates binary data, it is possible to include executable 622 content in an Ogg bitstream. This can be an issue with applications 623 that are implemented using the Ogg format, especially when Ogg is 624 used for streaming or file transfer in a networking scenario. As 625 626 627 628 Pfeiffer Informational [Page 11] 629 631 RFC 3533 OGG May 2003 632 633 634 such, Ogg does not pose a threat there. However, an application 635 decoding Ogg and its encapsulated content bitstreams has to ensure 636 correct handling of manipulated bitstreams, of buffer overflows and 637 the like. 638 639 8. References 640 641 [1] Walleij, L., "The application/ogg Media Type", RFC 3534, May 642 2003. 643 644 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 645 Levels", BCP 14, RFC 2119, March 1997. 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 Pfeiffer Informational [Page 12] 686 688 RFC 3533 OGG May 2003 689 690 691 Appendix A. Glossary of terms and abbreviations 692 693 bos page: The initial page (beginning of stream) of a logical 694 bitstream which contains information to identify the codec type 695 and other decoding-relevant information. 696 697 chaining (or sequential multiplexing): Concatenation of two or more 698 complete physical Ogg bitstreams. 699 700 eos page: The final page (end of stream) of a logical bitstream. 701 702 granule position: An increasing position number for a specific 703 logical bitstream stored in the page header. Its meaning is 704 dependent on the codec for that logical bitstream and specified in 705 a specific media mapping. 706 707 grouping (or concurrent multiplexing): Interleaving of pages of 708 several logical bitstreams into one complete physical Ogg 709 bitstream under the restriction that all bos pages of all grouped 710 logical bitstreams MUST appear before any data pages. 711 712 lacing value: An entry in the segment table of a page header 713 representing the size of the related segment. 714 715 logical bitstream: A sequence of bits being the result of an encoded 716 media stream. 717 718 media mapping: A specific use of the Ogg encapsulation format 719 together with a specific (set of) codec(s). 720 721 (Ogg) packet: A subpart of a logical bitstream that is created by the 722 encoder for that bitstream and represents a meaningful entity for 723 the encoder, but only a sequence of bits to the Ogg encapsulation. 724 725 (Ogg) page: A physical bitstream consists of a sequence of Ogg pages 726 containing data of one logical bitstream only. It usually 727 contains a group of contiguous segments of one packet only, but 728 sometimes packets are too large and need to be split over several 729 pages. 730 731 physical (Ogg) bitstream: The sequence of bits resulting from an Ogg 732 encapsulation of one or several logical bitstreams. It consists 733 of a sequence of pages from the logical bitstreams with the 734 restriction that the pages of one logical bitstream MUST come in 735 their correct temporal order. 736 737 738 739 740 741 742 Pfeiffer Informational [Page 13] 743 745 RFC 3533 OGG May 2003 746 747 748 (Ogg) segment: The Ogg encapsulation process splits each packet into 749 chunks of 255 bytes plus a last fractional chunk of less than 255 750 bytes. These chunks are called segments. 751 752 Appendix B. Acknowledgements 753 754 The author gratefully acknowledges the work that Christopher 755 Montgomery and the Xiph.Org foundation have done in defining the Ogg 756 multimedia project and as part of it the open file format described 757 in this document. The author hopes that providing this document to 758 the Internet community will help in promoting the Ogg multimedia 759 project at http://www.xiph.org/. Many thanks also for the many 760 technical and typo corrections that C. Montgomery and the Ogg 761 community provided as feedback to this RFC. 762 763 Author's Address 764 765 Silvia Pfeiffer 766 CSIRO, Australia 767 Locked Bag 17 768 North Ryde, NSW 2113 769 Australia 770 771 Phone: +61 2 9325 3141 772 EMail: Silvia.Pfeiffer (a] csiro.au 773 URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/ 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 Pfeiffer Informational [Page 14] 800 802 RFC 3533 OGG May 2003 803 804 805 Full Copyright Statement 806 807 Copyright (C) The Internet Society (2003). All Rights Reserved. 808 809 This document and translations of it may be copied and furnished to 810 others, and derivative works that comment on or otherwise explain it 811 or assist in its implementation may be prepared, copied, published 812 and distributed, in whole or in part, without restriction of any 813 kind, provided that the above copyright notice and this paragraph are 814 included on all such copies and derivative works. However, this 815 document itself may not be modified in any way, such as by removing 816 the copyright notice or references to the Internet Society or other 817 Internet organizations, except as needed for the purpose of 818 developing Internet standards in which case the procedures for 819 copyrights defined in the Internet Standards process must be 820 followed, or as required to translate it into languages other than 821 English. 822 823 The limited permissions granted above are perpetual and will not be 824 revoked by the Internet Society or its successors or assigns. 825 826 This document and the information contained herein is provided on an 827 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 828 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 829 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 830 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 831 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 832 833 Acknowledgement 834 835 Funding for the RFC Editor function is currently provided by the 836 Internet Society. 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 Pfeiffer Informational [Page 15] 857 859
