[theora-dev] Ogg IETF standard (was: Re: [vorbis-dev] application/ogg status update)

Silvia.Pfeiffer at csiro.au Silvia.Pfeiffer at csiro.au
Thu Nov 14 19:54:53 PST 2002



Hi all,

orry for cross-posting, but I believe both developer communities should
be interested in this.

In order to get Ogg accepted as application/ogg MIME type, there was a
requirement by the IETF to get an RFC written on the Ogg encapsulation
format. I have now authored a draft of that document and would like to
get input from the community and especially from Monty. Linus and I
would like to submit it asap to IETF (their next meeting is next week).
Please could everybody help me to make sure I have not made any
mistakes!

In addition, as I have copied many words and paragraphs from the online
documents, which I presume were authored by you, Monty, I would like to
suggest to include you as author in this RFC.

Let me know what you think ...

Cheers,

Silvia.

<p>Silvia Pfeiffer wrote:
> 
> Hi Linus,
> 
> I'm just wondering how much further you got with writing the RFC on the
> Ogg stream/file format (and of course the RFC on the application/ogg
> MIME type).
> 
> I would like to offer my help in writing an RFC on the "Ogg media
> encapsulation format" and in pursuing it with the IETF for
> standardisation. We could e.g. write up a document in RFC-compliant
> format (see RFC2629) rather quickly by using the "xml2rfc" tools
> provided by IETF.
> 
> I believe this effort is necessary and an excellent way to further the
> publicity of Ogg and all the related media encoders. I'd be very happy
> to get involved as I'd like to support the excellent efforts of this
> community.
> 
> Cheers,
> 
> Silvia.
> 
> Linus Walleij wrote:
> >
> > On Mon, 26 Aug 2002 Silvia.Pfeiffer at csiro.au wrote:
> >
> > > are you planning to write an RFC on the Ogg file format or on the ogg
> > > vorbis encoding format? Also, are you thinking about getting
> > > audio/ogg-vorbis and video/ogg-vp3 registered as mime formats?
> >
> > I have written an RFC for the application/ogg MIME type, so to support
> > this I might have to write an RFC for the Ogg stream/file format. I yet
> > don't know if I have to do that though, as my aim was primarily to get the
> > mimetype registered.
> >
> > There is a definition for audio/vorbis that will be common for both RTP
> > streamed "raw" vorbis and Ogg-packaged vorbis. However it is not yet
> > finished, some guy in Finland is working with it.
> >
> > Noone has thought about video/theora (as I think it should be named) and
> > with the extreme complexity that has surrounded the RTP version of Vorbis
> > I really don't know which way to go with that. Any suggestions?
> >
> > Linus Walleij

<p>



<p>Network Working Group                                        S. Pfeiffer
Internet-Draft                                                  Xiph.Org
Expires: May 16, 2003                                  November 15, 2002

<p>                 The Ogg encapsulation format version 0
                                ogg_rfc

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 16, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes the Ogg bitstream format version 1.0, which
   is a general, freely-available encapsulation format for media
   streams.  It is capable to encapsulate any kind and number of video
   and audio encoding formats as well as other data streams in a single
   bitstream.

<p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                  [Page 1]

Internet-Draft                     OGG                     November 2002

<p>1. Introduction

   The Ogg bitstream format has been developed as a part of a larger
   project aimed at creating a set of components for the coding and
   decoding of multimedia content (codecs) which are to be freely
   available and freely re-implementable both in software and in
   hardware for the computing community at large, including the Internet
   community.  It is the intention of the Ogg developers represented by
   Xiph.Org that it be usable without intellectual property concerns.

   This document describes the Ogg bitstream format and how to use it to
   encapsulate one or several media bitstreams created by one or several
   encoders.  The Ogg transport bitstream is designed to provide
   framing, error protection and seeking structure for higher-level
   codec streams that consist of raw, unencapsulated data packets, such
   as the Vorbis audio codec or the upcoming Tarkin and Theora video
   codecs.  It is capable to interleave different binary media and other
   time-continuous data streams that are prepared by an encoder as a
   sequence of data packets.  Ogg provides enough information to
   properly separate data back into such encoder created data packets at
   the original packet boundaries without relying on decoding to find
   packet boundaries.

   Please note that there is a related document containing all required
   information to register application/ogg as MIME type.  It is
   currently being processed as Internet-Draft: application/ogg MIME
   type I-D [1].

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                  [Page 2]

Internet-Draft                     OGG                     November 2002

<p>2. Definitions

   For describing the Ogg encapsulation process, a set of terms will be
   used whose meaning needs to be well understood.  Therefore, some of
   the most fundamental terms are defined now before we start with the
   description of the requirements for a generic media stream
   encapsulation format, the process of encapsulation, and the concrete
   format of the Ogg bitstream.  See the Appendix for a more complete
   glossary.

   The result of an Ogg encapsulation is called the "Physical (Ogg)
   Bitstream".  It encapsulates one or several encoder-created
   bitstreams, which are called "Logical Bitstreams".  A logical
   bitstream which is provided to the Ogg encapsulation process has a
   structure, i.e.  it is split up into a sequence of so-called
   "Packets".  The packets are created by the encoder of that logical
   bitstream and represent meaningful entities for that encoder only
   (e.g.  an uncompressed stream may use video frames as packets).  They
   do not contain boundary information - strung together they appear to
   be streams of random bytes with no landmarks.

   Please note that the term "packet" is not used in this document to
   signify entities for transport over a network.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                  [Page 3]

Internet-Draft                     OGG                     November 2002

<p>3. Requirements for a generic encapsulation format

   The design idea behind Ogg was to provide a generic, linear media
   transport format to enable both file-based storage and stream-based
   transmission of one or several interleaved media streams independent
   of the encoding format of the media data.  Such an encapsulation
   format needs to provide:

   o  framing for logical bitstreams.

   o  interleaving of different logical bitstreams.

   o  detection of corruption.

   o  recapture after a parsing error.

   o  position landmarks for direct random access.

   o  streaming capability (i.e.  no seeking is required to build a 100%
      complete bitstream).

   o  small overhead.

   o  simplicity to be fast.

   o  simple concatenation mechanism.

   All of these design considerations have been taken into consideration
   for Ogg.  Ogg supports framing and interleaving of logical
   bitstreams, seeking landmarks, detection of corruption, and stream
   resynchronisation after a parsing error with no more than
   approximately 1-2% overhead.  It is a generic framework to perform
   encapsulation of time-continuous bitstreams.  It does not know any
   specifics about the codec data that it encapsulates and is thus
   independent of any media codec.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                  [Page 4]

Internet-Draft                     OGG                     November 2002

<p>4. The Ogg bitstream format

   A physical Ogg bitstream consists of multiple logical bitstreams
   interleaved in so-called "Pages".  Whole pages are taken in order
   from multiple logical bitstreams multiplexed at the page level.  The
   logical bitstreams are identified by a unique serial number in the
   header of each page of the physical bitstream.  This unique serial
   number is created randomly and does not have any connection to the
   content or encoder of the logical bitstream it represents.  Pages of
   all logical bistreams are concurrently interleaved, but they need not
   be in a regular order - they only require to be consecutive within
   the logical bitstream.  Ogg demultiplexing reconstructs the original
   logical bitstreams from the physical bitstream by taking the pages in
   order from the physical bitstream and redirecting them into the
   appropriate logical decoding entity.

   Each Ogg page contains only one type of data as it belongs to one
   logical bitstream only.  Pages are of variable size and have a page
   header containing encapsulation and error recovery information.  Each
   logical bitstream in a physical Ogg bitstream starts with a special
   start page (bos=beginning of stream) and ends with a special page
   (eos=end of stream).  The bos page contains information to identify
   the codec type and any additional information to set up the decoding
   process.  The format of that page is therefore dependent on the codec
   and therefore must be given in the encoding specification of that
   logical bitstream type.  An example for such a media mapping is "Ogg
   Vorbis", which provides the name and revision of the Vorbis codec,
   the audio rate and the audio quality on the Ogg Vorbis bos page.

   Ogg knows two types of multiplexing: concurrent multiplexing (so-
   called "Grouping") and sequential multiplexing (so-called
   "Chaining").  Grouping defines how to interleave several logical
   bitstreams page-wise in the same physical bitstream.  Grouping is for
   example required for interleaving a video stream with several
   synchronised audio tracks using different codecs in different logical
   bitstreams.  Chaining on the other hand is defined to provide a
   simple mechanism to concatenate physical Ogg bitstreams as is often
   required for streaming applications.

   In grouping, all bos pages of all logical bitstreams must appear
   together at the beginning of the Ogg bitstream.  The media mapping
   specifies the order of the initial pages.  For example, grouping of a
   specific Ogg video and Ogg audio bitstream may specify that the
   physical bitstream must begin with the bos page of the logical video
   bitstream followed by the bos page of the audio bitstream.  Unlike
   bos pages eos pages for the logical bitstreams need not all occur
   contiguously.  Eos pages may be 'nil' pages, that is, pages
   containing no content but simply a page header with position

<p><p>Pfeiffer                  Expires May 16, 2003                  [Page 5]

Internet-Draft                     OGG                     November 2002

<p>   information and the eos flag set in the page header.  Each grouped
   logical bitstream must have a unique serial number within the scope
   of the physical bitstream.

   In chaining, complete logical bitstreams are concatenated.  The
   bitstreams do not overlap, i.e.  the eos page of a given logical
   bistream is immediately followed by the bos page of the next.  Each
   chained logical bitstream must have a unique serial number within the
   scope of the physical bitstream.

   It is possible to consecutively chain groups of concurrently
   multiplexed bitstreams.  The groups, when unchained, must stand on
   their own as a valid concurrently multiplexed bitstream.  The
   following diagram shows a schematic example of such a physical
   bitstream that obeys all the rules of both grouped and chained
   multiplexed bitstreams.

               physical bitstream with pages of
       different logical bitstreams grouped and chained
   -------------------------------------------------------------
   |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#|
   -------------------------------------------------------------
    bos bos bos             eos           eos eos bos       eos

<p>   In this example, there are two chained physical bitstreams, the first
   of which is a grouped stream of three logical bitstreams A, B, and C.
   The second physical bitstream is chained after the end of the grouped
   bitstream, which ends after the last eos page of all its grouped
   logical bitstreams.  As can be seen, grouped bitstreams begin
   together - all of the eos pages must appear before any data pages.
   It can also be seen that pages of concurrently multiplexed bitstreams
   need not conform to a regular order.  And it can be seen that a
   grouped bitstream can end long before the other bitstreams in the
   group end.

   Ogg does not know any specifics about the codec data except that each
   logical bitstream belongs to a different codec, the data from the
   codec comes in order and has position markers (so-called "Granule
   positions").  Ogg does not have a concept of 'time': it only knows
   about sequentially increasing, unitless position markers.  An
   application can only get temporal information through higher layers
   which have access to the codec APIs to assign and convert granule
   positions or time.

   A specific definition of a media mapping using Ogg may put further
   constraints on its specific use of the Ogg bitstream format.  For
   example, a specific media mapping may require that all the eos pages

<p><p>Pfeiffer                  Expires May 16, 2003                  [Page 6]

Internet-Draft                     OGG                     November 2002

<p>   for all grouped bitstreams need to appear in direct sequence.  An
   example for a media mapping is the specification of "Ogg Vorbis"
   which uses the Ogg framework to encapsulate Vorbis-encoded audio data
   for stream-based storage (such as files) and transport (such as TCP
   streams or pipes).  Ogg Vorbis puts a further constraint onto Ogg by
   specifying that concurrent multiplexing is not allowed in Ogg Vorbis
   files.  Another example is the upcoming Ogg Theora specification.
   Ogg Theora encapsulates a Vorbis-encoded audio bitstream and a
   Tarkin-encoded video bitstream in a single physical Ogg bitstream.
   As Ogg does not specify temporal relationships between the
   encapsulated concurrently multiplexed bitstreams, the temporal
   synchronisation between the audio and video stream will be specified
   in this media mapping.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                  [Page 7]

Internet-Draft                     OGG                     November 2002

<p>5. The encapsulation process

   The process of multiplexing different logical bitstreams happens at
   the level of pages as described above.  The bitstreams provided by
   encoders are however handed over to Ogg as so-called "Packets" with
   packet boundaries dependent on the encoding format.  The process of
   encapsulating packets into pages will be described now.

   From Ogg's perspective, packets can be of any arbitrary size,
   although a nominal size of approximately 4-8 kByte is recommended.
   As Ogg pages have a maximum size of about 64 kByte, sometimes a
   packet has to be distributed over several pages.  To simplify that
   process, Ogg divides each packet into 255 byte long chunks plus a
   final usually shorter chunk.  These chunks are called "Ogg Segments".
   They are only a logical construct and do not have a header for
   themselves.

   A group of contiguous segments is wrapped into a variable lenght page
   preceeded by a header.  A segment table in the page header tells
   about the "Lacing values" (sizes) of the segments included in the
   page.  A flag in the page header tells whether a page contains a
   packet continued from a previous page.  Note that a lacing value of
   255 implies that a second lacing value follows in the packet, and a
   value of less than 255 marks the end of the packet after that many
   additional bytes.  A packet of 255 bytes (or a multiple of 255 bytes)
   is terminated by a lacing value of 0.  Note also that a 'nil' (zero
   length) packet is not an error; it consists of nothing more than a
   lacing value of zero in the header.

   The encoding is optimised for speed and the expected case of the
   majority of packets being between 50 and 200 bytes large.  This
   encoding both avoids imposing a maximum packet size as well as
   imposing minimum overhead on small packets.  In contrast, e.g.
   simply using two bytes at the head of every packet and having a max
   packet size of 32 kBytes would always penalize small packets (< 255
   bytes, the typical case) with twice the segmentation overhead.  Using
   the lacing values as suggested, small packets see the minimum
   possible byte-aligned overhead (1 byte) and large packets (>512
   bytes) see a fairly constant ~0.5% overhead on encoding space.

   The following diagram shows a schematic example of a media mapping
   using Ogg and grouped logical bitstreams:

<p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                  [Page 8]

Internet-Draft                     OGG                     November 2002

<p>            logical bitstream with packet boundaries
   -----------------------------------------------------------------
   > |       packet_1             | packet_2         | packet_3 |  <
   -----------------------------------------------------------------

                       |segmentation (logically only)
                       v

        packet_1 (5 segments)          packet_2 (4 segs)    p_3 (2 segs)
       ------------------------------ -------------------- ------------
   ..  |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | ..
       ------------------------------ -------------------- ------------

                       | page encapsulation
                       v

    page_1 (of packet_1)    page_2 (of packet_1)   page_3 (of packet_2)
   ------------------------   ----------------   ------------------------
   |H|------------------- |   |H|----------- |   |H|------------------- |
   |D||seg_1|seg_2|seg_3| |   |D|seg_4|s_5 | |   |D||seg_1|seg_2|seg_3| | ...
   |R|------------------- |   |R|----------- |   |R|------------------- |
   ------------------------   ----------------   ------------------------

                        |
    pages of            |
    other    --------|  |
    logical         -------
    bitstreams      | MUX |
                    -------
                       |
                       v

                page_1  page_2          page_3
        ------  ------  -------  -----  -------
   ...  ||   |  ||   |  ||    |  ||  |  ||    |  ...
        ------  ------  -------  -----  -------
                physical Ogg bitstream

   In this example we take a snapshot of the encapsulation process of
   one logical bitstream.  We can see part of that bitstream's
   subdivision into packets as provided by the codec.  The Ogg
   encapsulation process chops up the packets into segments.  The
   packets in this example are rather large such that packet_1 is split
   into 5 segments - 4 segments with 255 bytes and a final smaller one.
   Packet_2 is split into 4 segments - 3 segments with 255 bytes and a
   final very small one - and packet_3 is split into two segments.  The
   encapsulation process then creates pages, which are quite small in
   this example.  Page_1 consists of the first three segments of

<p><p>Pfeiffer                  Expires May 16, 2003                  [Page 9]

Internet-Draft                     OGG                     November 2002

<p>   packet_1, page_2 contains the remaining 2 segments from packet_1, and
   page_3 contains the first three pages of packet_2.  Finally, this
   logical bitstream is multiplexed into a physical Ogg bitstream with
   pages of other logical bitstreams.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 10]

Internet-Draft                     OGG                     November 2002

<p>6. The Ogg page format

   A physical Ogg bitstream consists of a sequence of concatenated
   pages.  Pages are of variable size, usually 4-8 kB, maximum 65307
   bytes.  A page header contains all the required information to
   demultiplex the logical bitstreams out of the physical bitstream and
   to perform basic error recovery and landmarks for seeking.  Each page
   is a self-contained entity such that the page decode mechanism can
   recognize, verify, and handle single pages at a time without
   requiring the overall bitstream.

   The Ogg page header has the following format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | capture_pattern: Magic number for page start "OggS"           | 0-3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | version       | header_type   | granule_position              | 4-7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | 8-11
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               | bitstream_serial_number       | 12-15
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               | page_sequence_number          | 16-19
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               | CRC_checksum                  | 20-23
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |page_segments  | segment_table | 24-27
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...                                                           | 28-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The LSb (least significant bit) comes first in the Bytes.  Fields
   with more than one byte length are encoded LSB (least significant
   byte) first.

   The fields in the page header have the following meaning:

   1.  capture_pattern: a 4 Byte field that signifies the beginning of a
       page.  It contains the magic numbers:

          0x4f 'O'

          0x67 'g'

          0x67 'g'

<p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 11]

Internet-Draft                     OGG                     November 2002

<p>          0x53 'S'

       It helps a decoder to find the page boundaries and regain
       synchronisation after parsing a corrupted stream.  Once the
       capture pattern is found, the decoder verifies page sync and
       integrity by computing and comparing the checksum.

   2.  stream_structure_version: 1 Byte signifying the version number of
       the Ogg file format used in this stream (this document specifies
       version 0).

   3.  header_type_flag: the bits in this 1 Byte field identify the
       specific type of this page.

       *  bit 0x01

          set: page contains data of a media frame continued from the
             previous page

          unset: page contains a fresh media frame

       *  bit 0x02

          set: this is the first page of a logical bitstream (bos)

          unset: this page is not a first page

       *  bit 0x04

          set: this is the last page of a logical bitstream (eos)

          unset: this page is not a last page

   4.  granule_position: a 8 Byte field containing position information.
       For example, for an audio stream it contains the total number of
       PCM samples encoded after including all frames finished on this
       page.  For a video stream it contains the total number of video
       frames encoded after this page.  This is a hint for the decoder
       and gives it some timing and position information.  It's meaning
       is dependent on the codec for that logical bitstream and
       specified in a specific media mapping.

   5.  bitstream_serial_number: a 4 Byte field containing the serial
       number by which the logical bitstream is identified.

   6.  page_sequence_number: a 4 Byte field containing the sequence
       number of the page so the decoder can identify page loss.

<p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 12]

Internet-Draft                     OGG                     November 2002

<p>   7.  CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of
       the page (including header with zero CRC field and page content).
       The generator polynomial is 0x04c11db7.

   8.  number_page_segments: 1 Byte giving the number of segment entries
       encoded in the segment table.

   9.  segment_table: number_page_segments Bytes containing the lacing
       values of all segments in this page.  Each Byte contains one
       lacing value.

   The total header size in bytes is given by:
   header_size = number_page_segments + 27 [Byte]

   The total page size in Bytes is given by:
   page_size = header_size + sum(lacing_values: 1..number_page_segments)
   [Byte]

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 13]

Internet-Draft                     OGG                     November 2002

<p>7. Security considerations

   The Ogg encapsulation format is a container format and only
   encapsulates content (such as Vorbis-encoded audio).  It does not
   provide for any generic encryption or signing of itself or its
   contained content bitstreams.  It however encapsulates any kind of
   content bitstream as long as there is a codec for it, and is thus
   capable to contain encrypted and signed content data.  It is also
   possible to add an external security mechanism that encrypts or signs
   an Ogg physical bistream and thus provides content confidentiality
   and authenticity.

   As Ogg enapsulates binary data, it is possible to include executable
   content in an Ogg bitstream.  This may be an issue with applications
   that are implemented using the Ogg format, especially when Ogg is
   used for streaming or file transfer in a networking scenario.  Ogg as
   such does not pose a threat there.  However, an application decoding
   Ogg and its encapsulated content bitstreams has to ensure correct
   handling of manipulated bitstreams, of buffer overflows and the like.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 14]

Internet-Draft                     OGG                     November 2002

<p>References

   [1]  Walleij, L., "Internet-Draft: The application/ogg Media Type",
        Internet-Draft XXXX, May 2002.

<p>Author's Address

   Silvia Pfeiffer
   For Xiph.Org

   EMail: Silvia.Pfeiffer at csiro.au

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 15]

Internet-Draft                     OGG                     November 2002

<p>Appendix A. Glossary of terms and abbreviations

   bos page: The initial page (beginning of stream) of a logical
      bitstream which contains information to identify the codec type
      and other decoding-relevant information.

   chaining (or sequential multiplexing): Concatenation of two or more
      complete physical Ogg bitstreams.

   eos page The final page (end of stream) of a logical bitstream.

   granule position An increasing position number for a specific logical
      bitstream stored in the page header.  It's meaning is dependent on
      the codec for that logical bitstream and specified in a specific
      media mapping.

   grouping (or concurrent multiplexing): Interleaving of pages of
      several logical bitstreams into one complete physical Ogg bistream
      under the restriction that all bos pages of all grouped logical
      bitstreams must appear before any data pages.

   lacing value: An entry in the segment table of a page header
      representing the size of the related segment.

   logical bistream: A sequence of bits being the result of an encoded
      media stream.

   media mapping: A specific use of the Ogg encapsulation format
      together with a specific (set of) codec(s).

   (Ogg) packet: A subpart of a logical bitstream that is created by the
      encoder for that bitstream and represents a meaningful entity for
      the encoder, but only a sequence of bits to the Ogg encapsulation.

   (Ogg) page: A physical bitstream consists of a sequence of Ogg pages
      containing data of one logical bitstream only.  It usually
      contains a group of contiguous segments of one packet only, but
      sometimes packets are too large and must be split over several
      pages.

   physical (Ogg) bitstream: The sequence of bits resulting from an Ogg
      encapsulation of one or several logical bitstreams.  It consists
      of a sequence of pages from the logical bitstreams with the
      restriction that the pages of one logical bitstream must come in
      their correct temporal order.

   (Ogg) segment: The Ogg encapsulation process splits each packet into
      chunks of 255 bytes plus a last fractional chunk of less than 255

<p><p>Pfeiffer                  Expires May 16, 2003                 [Page 16]

Internet-Draft                     OGG                     November 2002

<p>      bytes.  These chunks are called segments.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 17]

Internet-Draft                     OGG                     November 2002

<p>Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

<p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p><p>Pfeiffer                  Expires May 16, 2003                 [Page 18]


--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Theora-dev mailing list