rfc3533.txt

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


RFC 3533                          OGG                           May 2003


   together - all of the bos 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
   for all grouped bitstreams need to appear in direct sequence.  An
   example for a media mapping is the specification of "Ogg Vorbis".
   Another example is the upcoming "Ogg Theora" specification which
   encapsulates Theora-encoded video data and usually comes multiplexed
   with a Vorbis stream for an Ogg containing synchronised audio and
   video.  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.  To enable streaming, pages from various
   logical bitstreams will typically be interleaved in chronological
   order.

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.  A
   specific media mapping will define how to group or break up packets
   from a specific media encoder.  As Ogg pages have a maximum size of
   about 64 kBytes, 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 shorter chunk.  These chunks
   are called "Ogg Segments".  They are only a logical construct and do
   not have a header for themselves.





Pfeiffer                     Informational                      [Page 6]

RFC 3533                          OGG                           May 2003


   A group of contiguous segments is wrapped into a variable length page
   preceded 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 optimized for speed and the expected case of the
   majority of packets being between 50 and 200 bytes large.  This is a
   design justification rather than a recommendation.  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.




























Pfeiffer                     Informational                      [Page 7]

RFC 3533                          OGG                           May 2003


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

          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 (packet_1 data)   page_2 (pket_1 data)   page_3 (packet_2 data)
------------------------  ----------------  ------------------------
|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



Pfeiffer                     Informational                      [Page 8]

RFC 3533                          OGG                           May 2003


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

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 information needed 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.







Pfeiffer                     Informational                      [Page 9]

RFC 3533                          OGG                           May 2003


   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'

            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 packet continued from the previous
            page

         unset: page contains a fresh packet

      *  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: an 8 Byte field containing position information.
      For example, for an audio stream, it MAY contain the total number
      of PCM samples encoded after including all frames finished on this
      page.  For a video stream it MAY contain the total number of video



Pfeiffer                     Informational                     [Page 10]

RFC 3533                          OGG                           May 2003