From 8e94244f86e657e4113e35438e59cf5771882b25 Mon Sep 17 00:00:00 2001 From: Aki Date: Sun, 3 Mar 2024 12:51:03 +0100 Subject: libogg and libvorbis are no longer part of this source tree --- contrib/vorbis/doc/oggstream.html | 234 -------------------------------------- 1 file changed, 234 deletions(-) delete mode 100644 contrib/vorbis/doc/oggstream.html (limited to 'contrib/vorbis/doc/oggstream.html') diff --git a/contrib/vorbis/doc/oggstream.html b/contrib/vorbis/doc/oggstream.html deleted file mode 100644 index 6952ed9..0000000 --- a/contrib/vorbis/doc/oggstream.html +++ /dev/null @@ -1,234 +0,0 @@ - - - - - -Ogg Vorbis Documentation - - - - - - - -

- -

Ogg logical and physical bitstream overview

- -

Ogg bitstreams

- -

Ogg codecs use octet vectors of raw, compressed data -(packets). These compressed packets do not have any -high-level structure or boundary information; strung together, they -appear to be streams of random bytes with no landmarks.

- -

Raw packets may be used directly by transport mechanisms that provide -their own framing and packet-separation mechanisms (such as UDP -datagrams). For stream based storage (such as files) and transport -(such as TCP streams or pipes), Vorbis and other future Ogg codecs use -the Ogg bitstream format to provide framing/sync, sync recapture -after error, landmarks during seeking, and enough information to -properly separate data back into packets at the original packet -boundaries without relying on decoding to find packet boundaries.

- -

Logical and physical bitstreams

- -

Raw packets are grouped and encoded into contiguous pages of -structured bitstream data called logical bitstreams. A -logical bitstream consists of pages, in order, belonging to a single -codec instance. Each page is a self contained entity (although it is -possible that a packet may be split and encoded across one or more -pages); that is, the page decode mechanism is designed to recognize, -verify and handle single pages at a time from the overall bitstream.

- -

Multiple logical bitstreams can be combined (with restrictions) into a -single physical bitstream. A physical bitstream consists of -multiple logical bitstreams multiplexed at the page level and may -include a 'meta-header' at the beginning of the multiplexed logical -stream that serves as identification magic. Whole pages are taken in -order from multiple logical bitstreams and combined into a single -physical stream of pages. The decoder 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. The simplest physical bitstream -is a single, unmultiplexed logical bitstream with no meta-header; this -is referred to as a 'degenerate stream'.

- -

Ogg Logical Bitstream Framing discusses -the page format of an Ogg bitstream, the packet coding process -and logical bitstreams in detail. The remainder of this document -specifies requirements for constructing finished, physical Ogg -bitstreams.

- -

Mapping Restrictions

- -

Logical bitstreams may not be mapped/multiplexed into physical -bitstreams without restriction. Here we discuss design restrictions -on Ogg physical bitstreams in general, mostly to introduce -design rationale. Each 'media' format defines its own (generally more -restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a -specific physical bitstream structure. -An 'Ogg A/V' bitstream (not currently specified) will also mandate a -specific, restricted physical bitstream format.

- -

additional end-to-end structure

- -

The framing specification defines -'beginning of stream' and 'end of stream' page markers via a header -flag (it is possible for a stream to consist of a single page). A -stream always consists of an integer number of pages, an easy -requirement given the variable size nature of pages.

- -

In addition to the header flag marking the first and last pages of a -logical bitstream, the first page of an Ogg bitstream obeys -additional restrictions. Each individual media mapping specifies its -own implementation details regarding these restrictions.

- -

The first page of a logical Ogg bitstream consists of a single, -small 'initial header' packet that includes sufficient information to -identify the exact CODEC type and media requirements of the logical -bitstream. The intent of this restriction is to simplify identifying -the bitstream type and content; for a given media type (or across all -Ogg media types) we can know that we only need a small, fixed -amount of data to uniquely identify the bitstream type.

- -

As an example, Ogg Vorbis places the name and revision of the Vorbis -CODEC, the audio rate and the audio quality into this initial header, -thus simplifying vastly the certain identification of an Ogg Vorbis -audio bitstream.

- -

sequential multiplexing (chaining)

- -

The simplest form of logical bitstream multiplexing is concatenation -(chaining). Complete logical bitstreams are strung -one-after-another in order. The bitstreams do not overlap; the final -page of a given logical bitstream is immediately followed by the -initial page of the next. Chaining is the only logical->physical -mapping allowed by Ogg Vorbis.

- -

Each chained logical bitstream must have a unique serial number within -the scope of the physical bitstream.

- -

concurrent multiplexing (grouping)

- -

Logical bitstreams may also be multiplexed 'in parallel' -(grouped). An example of grouping would be to allow -streaming of separate audio and video streams, using different codecs -and different logical bitstreams, in the same physical bitstream. -Whole pages from multiple logical bitstreams are mixed together.

- -

The initial pages of each logical bitstream must appear first; the -media mapping specifies the order of the initial pages. For example, -Ogg A/V will eventually specify an Ogg video bitstream with -audio. The mapping may specify that the physical bitstream must begin -with the initial page of a logical video bitstream, followed by the -initial page of an audio stream. Unlike initial pages, terminal pages -for the logical bitstreams need not all occur contiguously (although a -specific media mapping may require this; it is not mandated by the -generic Ogg stream spec). Terminal pages may be 'nil' pages, -that is, pages containing no content but simply a page header with -position information and the 'last page of bitstream' flag set in the -page header.

- -

Each grouped bitstream must have a unique serial number within the -scope of the physical bitstream.

- -

sequential and concurrent multiplexing

- -

Groups of concurrently multiplexed bitstreams may be chained -consecutively. Such a physical bitstream obeys all the rules of both -grouped and chained multiplexed streams; the groups, when unchained , -must stand on their own as a valid concurrently multiplexed -bitstream.

- -

multiplexing example

- -

Below, we present an example of a grouped and chained bitstream:

- -

stream

- -

In this example, we see pages from five total logical bitstreams -multiplexed into a physical bitstream. Note the following -characteristics:

- -

Grouped bitstreams begin together; all of the initial pages -must appear before any data pages. When concurrently multiplexed -groups are chained, the new group does not begin until all the -bitstreams in the previous group have terminated.
The pages of concurrently multiplexed bitstreams need not conform -to a regular order; the only requirement is that page n of a -logical bitstream follow page n-1 in the physical bitstream. -There are no restrictions on intervening pages belonging to other -logical bitstreams. (Tying page appearance to bitrate demands is one -logical strategy, ie, the page appears at the chronological point -where decode requires more information).

- -

- - - -- cgit v1.1