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