rfc3533.txt

mediastreamer2是开源的网络传输媒体流的库

Network Working Group                                        S. Pfeiffer
Request for Comments: 3533                                         CSIRO
Category: Informational                                         May 2003


                 The Ogg Encapsulation Format Version 0

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

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

Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [2].

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3. Requirements for a generic encapsulation format  . . . . . . .   3
   4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . .   3
   5. The encapsulation process  . . . . . . . . . . . . . . . . . .   6
   6. The Ogg page format  . . . . . . . . . . . . . . . . . . . . .   9
   7. Security Considerations  . . . . . . . . . . . . . . . . . . .  11
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   A. Glossary of terms and abbreviations  . . . . . . . . . . . . .  13
   B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  14
      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  14
      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  15







Pfeiffer                     Informational                      [Page 1]

RFC 3533                          OGG                           May 2003


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 of interleaving 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 the MIME type application/ogg has been registered
   with the IANA [1].

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, 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.





Pfeiffer                     Informational                      [Page 2]

RFC 3533                          OGG                           May 2003


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

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 of arbitrary positions
      in the bitstream.

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

   o  small overhead (i.e., use no more than approximately 1-2% of
      bitstream bandwidth for packet boundary marking, high-level
      framing, sync and seeking).

   o  simplicity to enable fast parsing.

   o  simple concatenation mechanism of several physical bitstreams.

   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.

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



Pfeiffer                     Informational                      [Page 3]

RFC 3533                          OGG                           May 2003


   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 bitstreams are concurrently interleaved, but they need
   not be in a regular order - they are only required 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 uniquely identify the codec type
   and MAY contain information to set up the decoding process.  The bos
   page SHOULD also contain information about the encoded media - for
   example, for audio, it should contain the sample rate and number of
   channels.  By convention, the first bytes of the bos page contain
   magic data that uniquely identifies the required codec.  It is the
   responsibility of anyone fielding a new codec to make sure it is
   possible to reliably distinguish his/her codec from all other codecs
   in use.  There is no fixed way to detect the end of the codec-
   identifying marker.  The format of the bos page is dependent on the
   codec and therefore MUST be given in the encapsulation specification
   of that logical bitstream type.  Ogg also allows but does not require
   secondary header packets after the bos page for logical bitstreams
   and these must also precede any data packets in any logical
   bitstream.  These subsequent header packets are framed into an
   integral number of pages, which will not contain any data packets.
   So, a physical bitstream begins with the bos pages of all logical
   bitstreams containing one initial header packet per page, followed by
   the subsidiary header packets of all streams, followed by pages
   containing data packets.

   The encapsulation specification for one or more logical bitstreams is
   called a "media mapping".  An example for a media mapping is "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 provides the name and
   revision of the Vorbis codec, the audio rate and the audio quality on
   the Ogg Vorbis bos page.  It also uses two additional header pages
   per logical bitstream.  The Ogg Vorbis bos page starts with the byte
   0x01, followed by "vorbis" (a total of 7 bytes of identifier).




Pfeiffer                     Informational                      [Page 4]

RFC 3533                          OGG                           May 2003


   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 needed 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
   needed 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, the 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
   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
   bitstream 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

   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



Pfeiffer                     Informational                      [Page 5]