forked from LosaDev/ls-2019-source
LosaDev source snapshot 2019
This commit is contained in:
LosaDev committed
commit
c198676e97
20588 files changed
+8812878
No files matched your search
@@ -0,0 +1,11 @@
|
||||
## Process this with automake to create Makefile.in
|
||||
|
||||
AUTOMAKE_OPTIONS = foreign
|
||||
|
||||
SUBDIRS = ogg
|
||||
|
||||
docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)
|
||||
|
||||
doc_DATA = index.html framing.html oggstream.html white-xifish.png stream.png white-ogg.png
|
||||
|
||||
EXTRA_DIST = $(doc_DATA)
|
||||
@@ -0,0 +1,395 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
|
||||
src="vorbisword2.png" border=0></a></nobr><p>
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg logical bitstream framing
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 14, 2002</em><br>
|
||||
|
||||
<h2>Ogg bitstreams</h2>
|
||||
|
||||
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 Tarkin video codec.
|
||||
|
||||
<h2>Application example: Vorbis</h2>
|
||||
Vorbis encodes short-time blocks of PCM data into raw packets of
|
||||
bit-packed data. These 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 uses 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.<p>
|
||||
|
||||
<h2>Design constraints for Ogg bitstreams</h2>
|
||||
|
||||
<ol><li>True streaming; we must not need to seek to build a 100%
|
||||
complete bitstream.
|
||||
|
||||
<li> Use no more than approximately 1-2% of bitstream bandwidth for
|
||||
packet boundary marking, high-level framing, sync and seeking.
|
||||
|
||||
<li> Specification of absolute position within the original sample
|
||||
stream.
|
||||
|
||||
<li> Simple mechanism to ease limited editing, such as a simplified
|
||||
concatenation mechanism.
|
||||
|
||||
<li> Detection of corruption, recapture after error and direct, random
|
||||
access to data at arbitrary positions in the bitstream.
|
||||
</ol>
|
||||
|
||||
<h2>Logical and Physical Bitstreams</h2>
|
||||
|
||||
A <em>logical</em> Ogg bitstream is a contiguous stream of
|
||||
sequential pages belonging only to the logical bitstream. A
|
||||
<em>physical</em> Ogg bitstream is constructed from one or more
|
||||
than one logical Ogg bitstream (the simplest physical bitstream
|
||||
is simply a single logical bitstream). We describe below the exact
|
||||
formatting of an Ogg logical bitstream. Combining logical
|
||||
bitstreams into more complex physical bitstreams is described in the
|
||||
<a href="oggstream.html">Ogg bitstream overview</a>. The exact
|
||||
mapping of raw Vorbis packets into a valid Ogg Vorbis physical
|
||||
bitstream is described in <a href="vorbis-stream.html">Vorbis
|
||||
bitstream mapping</a>.
|
||||
|
||||
<h2>Bitstream structure</h2>
|
||||
|
||||
An Ogg stream is structured by dividing incoming packets into
|
||||
segments of up to 255 bytes and then wrapping a group of contiguous
|
||||
packet segments into a variable length page preceded by a page
|
||||
header. Both the header size and page size are variable; the page
|
||||
header contains sizing information and checksum data to determine
|
||||
header/page size and data integrity.<p>
|
||||
|
||||
The bitstream is captured (or recaptured) by looking for the beginning
|
||||
of a page, specifically the capture pattern. Once the capture pattern
|
||||
is found, the decoder verifies page sync and integrity by computing
|
||||
and comparing the checksum. At that point, the decoder can extract the
|
||||
packets themselves.<p>
|
||||
|
||||
<h3>Packet segmentation</h3>
|
||||
|
||||
Packets are logically divided into multiple segments before encoding
|
||||
into a page. Note that the segmentation and fragmentation process is a
|
||||
logical one; it's used to compute page header values and the original
|
||||
page data need not be disturbed, even when a packet spans page
|
||||
boundaries.<p>
|
||||
|
||||
The raw packet is logically divided into [n] 255 byte segments and a
|
||||
last fractional segment of < 255 bytes. A packet size may well
|
||||
consist only of the trailing fractional segment, and a fractional
|
||||
segment may be zero length. These values, called "lacing values" are
|
||||
then saved and placed into the header segment table.<p>
|
||||
|
||||
An example should make the basic concept clear:<p>
|
||||
|
||||
<pre>
|
||||
<tt>
|
||||
raw packet:
|
||||
___________________________________________
|
||||
|______________packet data__________________| 753 bytes
|
||||
|
||||
lacing values for page header segment table: 255,255,243
|
||||
</tt>
|
||||
</pre>
|
||||
|
||||
We simply add the lacing values for the total size; the last lacing
|
||||
value for a packet is always the value that is less than 255. Note
|
||||
that this encoding both avoids imposing a maximum packet size as well
|
||||
as imposing minimum overhead on small packets (as opposed to, eg,
|
||||
simply using two bytes at the head of every packet and having a max
|
||||
packet size of 32k. Small packets (<255, the typical case) are
|
||||
penalized with twice the segmentation overhead). Using the lacing
|
||||
values as suggested, small packets see the minimum possible
|
||||
byte-aligned overheade (1 byte) and large packets, over 512 bytes or
|
||||
so, see a fairly constant ~.5% overhead on encoding space.<p>
|
||||
|
||||
Note that a lacing value of 255 implies that a second lacing value
|
||||
follows in the packet, and a value of < 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:<p>
|
||||
|
||||
<pre><tt>
|
||||
raw packet:
|
||||
_______________________________
|
||||
|________packet data____________| 255 bytes
|
||||
|
||||
lacing values: 255, 0
|
||||
</tt></pre>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h3>Packets spanning pages</h3>
|
||||
|
||||
Packets are not restricted to beginning and ending within a page,
|
||||
although individual segments are, by definition, required to do so.
|
||||
Packets are not restricted to a maximum size, although excessively
|
||||
large packets in the data stream are discouraged; the Ogg
|
||||
bitstream specification strongly recommends nominal page size of
|
||||
approximately 4-8kB (large packets are foreseen as being useful for
|
||||
initialization data at the beginning of a logical bitstream).<p>
|
||||
|
||||
After segmenting a packet, the encoder may decide not to place all the
|
||||
resulting segments into the current page; to do so, the encoder places
|
||||
the lacing values of the segments it wishes to belong to the current
|
||||
page into the current segment table, then finishes the page. The next
|
||||
page is begun with the first value in the segment table belonging to
|
||||
the next packet segment, thus continuing the packet (data in the
|
||||
packet body must also correspond properly to the lacing values in the
|
||||
spanned pages. The segment data in the first packet corresponding to
|
||||
the lacing values of the first page belong in that page; packet
|
||||
segments listed in the segment table of the following page must begin
|
||||
the page body of the subsequent page).<p>
|
||||
|
||||
The last mechanic to spanning a page boundary is to set the header
|
||||
flag in the new page to indicate that the first lacing value in the
|
||||
segment table continues rather than begins a packet; a header flag of
|
||||
0x01 is set to indicate a continued packet. Although mandatory, it
|
||||
is not actually algorithmically necessary; one could inspect the
|
||||
preceding segment table to determine if the packet is new or
|
||||
continued. Adding the information to the packet_header flag allows a
|
||||
simpler design (with no overhead) that needs only inspect the current
|
||||
page header after frame capture. This also allows faster error
|
||||
recovery in the event that the packet originates in a corrupt
|
||||
preceding page, implying that the previous page's segment table
|
||||
cannot be trusted.<p>
|
||||
|
||||
Note that a packet can span an arbitrary number of pages; the above
|
||||
spanning process is repeated for each spanned page boundary. Also a
|
||||
'zero termination' on a packet size that is an even multiple of 255
|
||||
must appear even if the lacing value appears in the next page as a
|
||||
zero-length continuation of the current packet. The header flag
|
||||
should be set to 0x01 to indicate that the packet spanned, even though
|
||||
the span is a nil case as far as data is concerned.<p>
|
||||
|
||||
The encoding looks odd, but is properly optimized for speed and the
|
||||
expected case of the majority of packets being between 50 and 200
|
||||
bytes (note that it is designed such that packets of wildly different
|
||||
sizes can be handled within the model; placing packet size
|
||||
restrictions on the encoder would have only slightly simplified design
|
||||
in page generation and increased overall encoder complexity).<p>
|
||||
|
||||
The main point behind tracking individual packets (and packet
|
||||
segments) is to allow more flexible encoding tricks that requiring
|
||||
explicit knowledge of packet size. An example is simple bandwidth
|
||||
limiting, implemented by simply truncating packets in the nominal case
|
||||
if the packet is arranged so that the least sensitive portion of the
|
||||
data comes last.<p>
|
||||
|
||||
<h3>Page header</h3>
|
||||
|
||||
The headering mechanism is designed to avoid copying and re-assembly
|
||||
of the packet data (ie, making the packet segmentation process a
|
||||
logical one); the header can be generated directly from incoming
|
||||
packet data. The encoder buffers packet data until it finishes a
|
||||
complete page at which point it writes the header followed by the
|
||||
buffered packet segments.<p>
|
||||
|
||||
<h4>capture_pattern</h4>
|
||||
|
||||
A header begins with a capture pattern that simplifies identifying
|
||||
pages; once the decoder has found the capture pattern it can do a more
|
||||
intensive job of verifying that it has in fact found a page boundary
|
||||
(as opposed to an inadvertent coincidence in the byte stream).<p>
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
0 0x4f 'O'
|
||||
1 0x67 'g'
|
||||
2 0x67 'g'
|
||||
3 0x53 'S'
|
||||
</tt></pre>
|
||||
|
||||
<h4>stream_structure_version</h4>
|
||||
|
||||
The capture pattern is followed by the stream structure revision:
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
4 0x00
|
||||
</tt></pre>
|
||||
|
||||
<h4>header_type_flag</h4>
|
||||
|
||||
The header type flag identifies this page's context in the bitstream:
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
5 bitflags: 0x01: unset = fresh packet
|
||||
set = continued packet
|
||||
0x02: unset = not first page of logical bitstream
|
||||
set = first page of logical bitstream (bos)
|
||||
0x04: unset = not last page of logical bitstream
|
||||
set = last page of logical bitstream (eos)
|
||||
</tt></pre>
|
||||
|
||||
<h4>absolute granule position</h4>
|
||||
|
||||
(This is packed in the same way the rest of Ogg data is packed; LSb
|
||||
of LSB first. Note that the 'position' data specifies a 'sample'
|
||||
number (eg, in a CD quality sample is four octets, 16 bits for left
|
||||
and 16 bits for right; in video it would likely be the frame number.
|
||||
It is up to the specific codec in use to define the semantic meaning
|
||||
of the granule position value). The position specified is the total
|
||||
samples encoded after including all packets finished on this page
|
||||
(packets begun on this page but continuing on to the next page do not
|
||||
count). The rationale here is that the position specified in the
|
||||
frame header of the last page tells how long the data coded by the
|
||||
bitstream is. A truncated stream will still return the proper number
|
||||
of samples that can be decoded fully.
|
||||
<p>
|
||||
A special value of '-1' (in two's complement) indicates that no packets
|
||||
finish on this page.
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
6 0xXX LSB
|
||||
7 0xXX
|
||||
8 0xXX
|
||||
9 0xXX
|
||||
10 0xXX
|
||||
11 0xXX
|
||||
12 0xXX
|
||||
13 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>stream serial number</h4>
|
||||
|
||||
Ogg allows for separate logical bitstreams to be mixed at page
|
||||
granularity in a physical bitstream. The most common case would be
|
||||
sequential arrangement, but it is possible to interleave pages for
|
||||
two separate bitstreams to be decoded concurrently. The serial
|
||||
number is the means by which pages physical pages are associated with
|
||||
a particular logical stream. Each logical stream must have a unique
|
||||
serial number within a physical stream:
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
14 0xXX LSB
|
||||
15 0xXX
|
||||
16 0xXX
|
||||
17 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>page sequence no</h4>
|
||||
|
||||
Page counter; lets us know if a page is lost (useful where packets
|
||||
span page boundaries).
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
18 0xXX LSB
|
||||
19 0xXX
|
||||
20 0xXX
|
||||
21 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>page checksum</h4>
|
||||
|
||||
32 bit CRC value (direct algorithm, initial val and final XOR = 0,
|
||||
generator polynomial=0x04c11db7). The value is computed over the
|
||||
entire header (with the CRC field in the header set to zero) and then
|
||||
continued over the page. The CRC field is then filled with the
|
||||
computed value.<p>
|
||||
|
||||
(A thorough discussion of CRC algorithms can be found in <a
|
||||
href="ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt">"A
|
||||
Painless Guide to CRC Error Detection Algorithms"</a> by Ross
|
||||
Williams <a
|
||||
href="mailto:[email protected]">[email protected]</a>.)
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
22 0xXX LSB
|
||||
23 0xXX
|
||||
24 0xXX
|
||||
25 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>page_segments</h4>
|
||||
|
||||
The number of segment entries to appear in the segment table. The
|
||||
maximum number of 255 segments (255 bytes each) sets the maximum
|
||||
possible physical page size at 65307 bytes or just under 64kB (thus
|
||||
we know that a header corrupted so as destroy sizing/alignment
|
||||
information will not cause a runaway bitstream. We'll read in the
|
||||
page according to the corrupted size information that's guaranteed to
|
||||
be a reasonable size regardless, notice the checksum mismatch, drop
|
||||
sync and then look for recapture).<p>
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
26 0x00-0xff (0-255)
|
||||
</tt></pre>
|
||||
|
||||
<h4>segment_table (containing packet lacing values)</h4>
|
||||
|
||||
The lacing values for each packet segment physically appearing in
|
||||
this page are listed in contiguous order.
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
27 0x00-0xff (0-255)
|
||||
[...]
|
||||
n 0x00-0xff (0-255, n=page_segments+26)
|
||||
</tt></pre>
|
||||
|
||||
Total page size is calculated directly from the known header size and
|
||||
lacing values in the segment table. Packet data segments follow
|
||||
immediately after the header.<p>
|
||||
|
||||
Page headers typically impose a flat .25-.5% space overhead assuming
|
||||
nominal ~8k page sizes. The segmentation table needed for exact
|
||||
packet recovery in the streaming layer adds approximately .5-1%
|
||||
nominal assuming expected encoder behavior in the 44.1kHz, 128kbps
|
||||
stereo encodings.<p>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
<a href="oggstream.html">Ogg logical and physical bitstream overview</a><br>
|
||||
<a href="framing.html">Ogg logical bitstream framing</a><br>
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
## Process this file with automake to produce Makefile.in
|
||||
|
||||
AUTOMAKE_OPTIONS = foreign
|
||||
|
||||
docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)/ogg
|
||||
|
||||
doc_DATA = bitpacking.html datastructures.html decoding.html encoding.html\
|
||||
general.html index.html ogg_packet.html ogg_page.html\
|
||||
ogg_page_bos.html ogg_page_continued.html ogg_page_eos.html\
|
||||
ogg_page_granulepos.html ogg_page_pageno.html ogg_page_serialno.html\
|
||||
ogg_page_version.html ogg_stream_clear.html ogg_stream_destroy.html\
|
||||
ogg_page_packets.html ogg_stream_eos.html ogg_stream_flush.html\
|
||||
ogg_stream_init.html ogg_stream_packetin.html ogg_stream_packetout.html\
|
||||
ogg_stream_pagein.html ogg_stream_pageout.html ogg_stream_reset.html\
|
||||
ogg_stream_state.html ogg_sync_buffer.html ogg_sync_clear.html\
|
||||
ogg_sync_destroy.html ogg_sync_init.html ogg_sync_pageout.html\
|
||||
ogg_sync_pageseek.html ogg_sync_reset.html ogg_sync_state.html\
|
||||
ogg_sync_wrote.html oggpack_adv.html oggpack_adv1.html\
|
||||
oggpack_bits.html oggpack_buffer.html\
|
||||
oggpack_bytes.html oggpack_get_buffer.html oggpack_look.html\
|
||||
oggpack_look1.html oggpack_read.html\
|
||||
oggpack_read1.html oggpack_readinit.html oggpack_reset.html\
|
||||
oggpack_write.html oggpack_writeclear.html oggpack_writeinit.html\
|
||||
overview.html reference.html style.css vorbis_comment.html\
|
||||
vorbis_info.html ogg_packet_clear.html ogg_page_checksum_set.html
|
||||
|
||||
EXTRA_DIST = $(doc_DATA)
|
||||
@@ -0,0 +1,99 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - Bitpacking Functions</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Bitpacking Functions</h1>
|
||||
<p>Libogg contains a basic bitpacking library that is useful for manipulating data within a buffer.
|
||||
<p>
|
||||
All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
|
||||
<p>
|
||||
|
||||
<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td><b>function</b></td>
|
||||
<td><b>purpose</b></td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_writeinit.html">oggpack_writeinit</a></td>
|
||||
<td>Initializes a buffer for writing using this bitpacking library.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_reset.html">oggpack_reset</a></td>
|
||||
<td>Clears and resets the buffer to the initial position.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_writeclear.html">oggpack_writeclear</a></td>
|
||||
<td>Frees the memory used by the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_readinit.html">oggpack_readinit</a></td>
|
||||
<td>Initializes a buffer for reading using this bitpacking library.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_write.html">oggpack_write</a></td>
|
||||
<td>Writes bytes to the specified location within the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_look.html">oggpack_look</a></td>
|
||||
<td>Look at a specified number of bits, <=32, without advancing the location pointer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_look1.html">oggpack_look1</a></td>
|
||||
<td>Looks at one bit without advancing the location pointer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_adv.html">oggpack_adv</a></td>
|
||||
<td>Advances the location pointer by a specified number of bits.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_adv1.html">oggpack_adv1</a></td>
|
||||
<td>Advances the location pointer by one bit.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_read.html">oggpack_read</a></td>
|
||||
<td>Reads a specified number of bits from the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_read1.html">oggpack_read1</a></td>
|
||||
<td>Reads one bit from the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_bytes.html">oggpack_bytes</a></td>
|
||||
<td>Returns the total number of bytes contained within the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_bits.html">oggpack_bits</a></td>
|
||||
<td>Returns the total number of bits contained within the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="oggpack_get_buffer.html">oggpack_get_buffer</a></td>
|
||||
<td>Returns a pointer to the buffer encapsulated within the <a href="oggpack_buffer.html">oggpack_buffer</a> struct.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,59 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - Base Data Structures</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Base Data Structures</h1>
|
||||
<p>Libogg uses several data structures to hold data and state information.
|
||||
<p>
|
||||
All the <b>libogg</b> specific data structures are declared in "ogg/ogg.h".
|
||||
<p>
|
||||
|
||||
<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td><b>datatype</b></td>
|
||||
<td><b>purpose</b></td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page.html">ogg_page</a></td>
|
||||
<td>This structure encapsulates data into one ogg bitstream page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_state.html">ogg_stream_state</a></td>
|
||||
<td>This structure contains current encode/decode data for a logical bitstream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_packet.html">ogg_packet</a></td>
|
||||
<td>This structure encapsulates the data and metadata for a single raw Ogg Vorbis packet.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_state.html">ogg_sync_state</a></td>
|
||||
<td>Contains bitstream synchronization information.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,100 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - Decoding</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Decoding</h1>
|
||||
<p>Libogg contains a set of functions used in the decoding process.
|
||||
<p>
|
||||
All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
|
||||
<p>
|
||||
<p>Decoding is based around the ogg synchronization layer. The <a href="ogg_sync_state.html">ogg_sync_state</a> struct coordinates between incoming data and the decoder. We read data into the synchronization layer, submit the data to the stream, and output raw packets to the decoder.
|
||||
<p>Decoding through the Ogg layer follows a specific logical sequence. A read loop follows these logical steps:
|
||||
<ul>
|
||||
<li>Expose a buffer using <a href="ogg_sync_buffer.html">ogg_sync_buffer()</a>.
|
||||
<li>Read data into the buffer, using fread() or a similar function.
|
||||
<li>Call <a href="ogg_sync_wrote.html">ogg_sync_wrote()</a> to tell the synchronization layer how many bytes you wrote into the buffer.
|
||||
<li>Write out the data using <a href="ogg_sync_pageout.html">ogg_sync_pageout</a>.
|
||||
<li>Submit the completed page to the streaming layer with <a href="ogg_stream_pagein.html">ogg_stream_pagein</a>.
|
||||
<li>Output a packet of data to the codec-specific decoding layer using <a href="ogg_stream_packetout.html">ogg_stream_packetout</a>.
|
||||
</ul>
|
||||
<p>In practice, streams are more complex, and Ogg also must handle headers, incomplete or dropped pages, and other errors in input.
|
||||
<br><br>
|
||||
|
||||
<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td><b>function</b></td>
|
||||
<td><b>purpose</b></td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_init.html">ogg_sync_init</a></td>
|
||||
<td>Initializes an Ogg bitstream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_clear.html">ogg_sync_clear</a></td>
|
||||
<td>Clears the status information from the synchronization struct.<td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_reset.html">ogg_sync_reset</a></td>
|
||||
<td>Resets the synchronization status to initial values.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_destroy.html">ogg_sync_destroy</a></td>
|
||||
<td>Frees the synchronization struct.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_buffer.html">ogg_sync_buffer</a></td>
|
||||
<td>Exposes a buffer from the synchronization layer in order to read data.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_wrote.html">ogg_sync_wrote</a></td>
|
||||
<td>Tells the synchronization layer how many bytes were written into the buffer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_pageseek.html">ogg_sync_pageseek</a></td>
|
||||
<td>Finds the borders of pages and resynchronizes the stream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_sync_pageout.html">ogg_sync_pageout</a></td>
|
||||
<td>Outputs a page from the synchronization layer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_pagein.html">ogg_stream_pagein</a></td>
|
||||
<td>Submits a complete page to the stream layer.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_packetout.html">ogg_stream_packetout</a></td>
|
||||
<td>Outputs a packet to the codec-specific decoding engine.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_packetpeek.html">ogg_stream_packetpeek</a></td>
|
||||
<td>Provides access to the next packet in the bitstream without
|
||||
advancing decoding.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,64 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - Encoding</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Encoding</h1>
|
||||
<p>Libogg contains a set of functions used in the encoding process.
|
||||
<p>
|
||||
All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
|
||||
<p>
|
||||
<p>When encoding, the encoding engine will output raw packets which must be placed into an Ogg bitstream.
|
||||
<p>Raw packets are inserted into the stream, and an <a href="ogg_page.html">ogg_page</a> is output when enough packets have been written to create a full page. The pages output are pointers to buffered packet segments, and can then be written out and saved as an ogg stream.
|
||||
<p>There are a couple of basic steps:
|
||||
<ul>
|
||||
<li>Use the encoding engine to produce a raw packet of data.
|
||||
<li>Call <a href="ogg_stream_packetin.html">ogg_stream_packetin</a> to submit a raw packet to the stream.
|
||||
<li>Use <a href="ogg_stream_pageout.html">ogg_stream_pageout</a> to output a page, if enough data has been submitted. Otherwise, continue submitting data.
|
||||
</ul>
|
||||
<br><br>
|
||||
|
||||
<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td><b>function</b></td>
|
||||
<td><b>purpose</b></td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_packetin.html">ogg_stream_packetin</a></td>
|
||||
<td>Submits a raw packet to the streaming layer, so that it can be formed into a page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_pageout.html">ogg_stream_pageout</a></td>
|
||||
<td>Outputs a completed page if the stream contains enough packets to form a full page.<td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_flush.html">ogg_stream_flush</a></td>
|
||||
<td>Forces any remaining packets in the stream to be returned as a page of any size.<td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,105 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - General Functions</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>General Functions</h1>
|
||||
<p>Libogg contains several functions which are generally useful when using Ogg streaming, whether encoding or decoding.
|
||||
<p>
|
||||
All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
|
||||
<p>
|
||||
<p>These functions can be used to manipulate some of the basic elements of Ogg - streams and pages. Streams and pages are important during both the encode and decode process.
|
||||
<br>
|
||||
|
||||
<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td><b>function</b></td>
|
||||
<td><b>purpose</b></td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_init.html">ogg_stream_init</a></td>
|
||||
<td>Initializes an Ogg bitstream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_clear.html">ogg_stream_clear</a></td>
|
||||
<td>Clears the storage within the Ogg stream, but does not free the stream itself.<td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_reset.html">ogg_stream_reset</a></td>
|
||||
<td>Resets the stream status to its initial position.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_destroy.html">ogg_stream_destroy</a></td>
|
||||
<td>Frees the entire Ogg stream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_stream_eos.html">ogg_stream_eos</a></td>
|
||||
<td>Indicates whether we are at the end of the stream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_version.html">ogg_page_version</a></td>
|
||||
<td>Returns the version of ogg_page that this stream/page uses</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_continued.html">ogg_page_continued</a></td>
|
||||
<td>Indicates if the current page contains a continued packet from the last page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_packets.html">ogg_page_packets</a></td>
|
||||
<td>Indicates the number of packets contained in a page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_bos.html">ogg_page_bos</a></td>
|
||||
<td>Indicates if the current page is the beginning of the stream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_eos.html">ogg_page_eos</a></td>
|
||||
<td>Indicates if the current page is the end of the stream.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_granulepos.html">ogg_page_granulepos</a></td>
|
||||
<td>Returns the precise playback location of this page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_serialno.html">ogg_page_serialno</a></td>
|
||||
<td>Returns the unique serial number of the logical bitstream associated with this page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_pageno.html">ogg_page_pageno</a></td>
|
||||
<td>Returns the sequential page number for this page.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_packet_clear.html">ogg_packet_clear</a><td>
|
||||
<td>Clears the ogg_packet structure.</td>
|
||||
</tr>
|
||||
<tr valign=top>
|
||||
<td><a href="ogg_page_checksum_set.html">ogg_page_checksum_set</a></td>
|
||||
<td>Checksums an ogg_page.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,39 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - Documentation</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Libogg Documentation</h1>
|
||||
|
||||
<p>
|
||||
Libogg contains necessary functionality to create, decode, and work with Ogg bitstreams.
|
||||
<p>This document explains how to use the libogg API in detail.
|
||||
<p>
|
||||
<a href="overview.html">libogg api overview</a><br>
|
||||
<a href="reference.html">libogg api reference</a><br>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,75 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - datatype - ogg_packet</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011015</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_packet</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h"</i></p>
|
||||
|
||||
<p>
|
||||
The ogg_packet struct encapsulates the data for a single raw packet of data
|
||||
and is used to transfer data between the ogg framing layer and the handling codec.
|
||||
<p>
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
typedef struct {
|
||||
unsigned char *packet;
|
||||
long bytes;
|
||||
long b_o_s;
|
||||
long e_o_s;
|
||||
|
||||
ogg_int64_t granulepos;
|
||||
ogg_int64_t packetno;
|
||||
|
||||
} ogg_packet;
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Relevant Struct Members</h3>
|
||||
<dl>
|
||||
<dt><i>packet</i></dt>
|
||||
<dd>Pointer to the packet's data. This is treated as an opaque type by the ogg layer.</dd>
|
||||
<dt><i>bytes</i></dt>
|
||||
<dd>Indicates the size of the packet data in bytes. Packets can be of arbitrary size.</dd>
|
||||
<dt><i>b_o_s</i></dt>
|
||||
<dd>Flag indicating whether this packet begins a logical bitstream. <tt>1</tt> indicates this is the first packet, <tt>0</tt> indicates any other position in the stream.</dd>
|
||||
<dt><i>e_o_s</i></dt>
|
||||
<dd>Flag indicating whether this packet ends a bitstream. <tt>1</tt> indicates the last packet, <tt>0</tt> indicates any other position in the stream.</dd>
|
||||
<dt><i>granulepos</i></dt>
|
||||
<dd>A number indicating the position of this packet in the decoded data. This is the last sample, frame or other unit of information ('granule') that can be completely decoded from this packet.</dd>
|
||||
<dt><i>packetno</i></dt>
|
||||
<dd>Sequential number of this packet in the ogg bitstream.<dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2001 xiph.org foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011015</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_packet_clear</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011218</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_packet_clear</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function clears the memory used by the <a href="ogg_packet.html">ogg_packet</a> struct, and frees the internal allocated memory, but does not free
|
||||
the structure itself.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_packet_clear(ogg_packet *op);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the ogg_packet struct to be cleared.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
None.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2001 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011218</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,74 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - datatype - ogg_page</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 200011015</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h"</i></p>
|
||||
|
||||
<p>
|
||||
The ogg_page struct encapsulates the data for an Ogg page.
|
||||
<p>
|
||||
Ogg pages are the fundamental unit of framing and interleave in an ogg bitstream.
|
||||
They are made up of packet segments of 255 bytes each. There can be as many as
|
||||
255 packet segments per page, for a maximum page size of a little under 64 kB.
|
||||
This is not a practical limitation as the segments can be joined across
|
||||
page boundaries allowing packets of arbitrary size. In practice pages are
|
||||
usually around 4 kB.
|
||||
<p>
|
||||
<p>For a complete description of ogg pages and headers, please refer to the <a href="../framing.html">framing document</a>.
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
typedef struct {
|
||||
unsigned char *header;
|
||||
long header_len;
|
||||
unsigned char *body;
|
||||
long body_len;
|
||||
} ogg_page;
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Relevant Struct Members</h3>
|
||||
<dl>
|
||||
<dt><i>header</i></dt>
|
||||
<dd>Pointer to the page header for this page. The exact contents of this header are defined in the framing spec document.</dd>
|
||||
<dt><i>header_len</i></dt>
|
||||
<dd>Length of the page header in bytes.</a>
|
||||
<dt><i>body</i></dt>
|
||||
<dd>Pointer to the data for this page.</dd>
|
||||
<dt><i>body_len</i></dt>
|
||||
<dd>Length of the body data in bytes.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2001 xiph.org foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg version - 20011015</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_bos</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_bos</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Indicates whether this page is at the beginning of the logical bitstream.
|
||||
<p>
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_bos(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
greater than 0 if this page is the beginning of a bitstream.</li>
|
||||
<li>
|
||||
0 if this page is from any other location in the stream.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_checksum_set</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011218</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_checksum_set</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Checksums an ogg_page.
|
||||
<p>
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_checksum_set(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to an ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
None.
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2001 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011218</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,64 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_version</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_continued</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Indicates whether this page contains packet data which has been continued from the previous page.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_continued(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
1 if this page contains packet data continued from the last page.</li>
|
||||
<li>
|
||||
0 if this page does not contain continued data.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_eos</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_eos</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Indicates whether this page is at the end of the logical bitstream.
|
||||
<p>
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_eos(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
greater than zero if this page contains the end of a bitstream.</li>
|
||||
<li>
|
||||
0 if this page is from any other location in the stream.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_granulepos</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_granulepos</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Returns the exact granular position of the packet data contained at the end of this page.
|
||||
<p>This is useful for tracking location when seeking or decoding.
|
||||
<p>For example, in audio codecs this position is the pcm sample number and in video this is the frame number.
|
||||
<p>
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_granulepos(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the specific last granular position of the decoded data contained in the page.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,75 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_packets</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011218</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_packets</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Returns the number of packets that are completed on this page. If the
|
||||
leading packet is begun on a previous page, but ends on this page, it's
|
||||
counted.
|
||||
<p>
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_packets(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
If a page consists of a packet begun on a previous page, and a new packet
|
||||
begun (but not completed) on this page, the return will be:<br>
|
||||
<br>
|
||||
ogg_page_packets(page) will return 1,<br>
|
||||
ogg_page_continued(paged) will return non-zero.<br>
|
||||
<br><br>
|
||||
If a page happens to be a single packet that was begun on a previous page, and
|
||||
spans to the next page (in the case of a three or more page packet), the
|
||||
return will be:<br>
|
||||
<br>
|
||||
ogg_page_packets(page) will return 0,<br>
|
||||
ogg_page_continued(page) will return non-zero.<br>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2001 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20011218</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_pageno</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_pageno</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Returns the sequential page number.
|
||||
<p>This is useful for ordering pages or determining when pages have been lost.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_pageno(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the page number for this page.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_serialno</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_serialno</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>Returns the unique serial number for the logical bitstream of this page. Each page contains the serial number for the logical bitstream that it belongs to.
|
||||
<p>
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_serialno(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the serial number for this page.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_page_version</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_page_version</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function returns the version of ogg_page used in this page.
|
||||
<p>In current versions of libogg, all ogg_page structs have the same version, so 0 should always be returned.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_page_version(ogg_page *og);
|
||||
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to the current ogg_page struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the version number. In the current version of Ogg, the version number is always 0. Nonzero return values indicate an error in page encoding.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,61 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_clear</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_clear</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function clears the memory used by the <a href="ogg_sync_state.html">ogg_stream_state</a> struct, but does not free it.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_clear(ogg_stream_state *os);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the ogg_stream_state struct to be cleared.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_destroy</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_destroy</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function frees the memory used by the <a href="ogg_stream_state.html">ogg_stream_state</a> struct.
|
||||
<p>This should be called when you are done working with an ogg stream. It can also be called to make sure that the struct does not exist.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_destroy(ogg_stream_state *os);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the ogg_stream_state struct to be destroyed.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_eos</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_eos</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function indicates whether we have reached the end of the stream or not.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_eos(ogg_stream_state *os);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the current ogg_stream_state struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>1 if we are at the end of the stream.</li>
|
||||
<li>
|
||||
0 if we have not yet reached the end of the stream.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,67 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_flush</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_flush</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function checks for remaining packets inside the stream and forces remaining packets into a page, regardless of the size of the page.
|
||||
<p>This should only be used when you want to flush an undersized page from the middle of the stream. Otherwise, <a href="ogg_stream_pageout.html">ogg_stream_pageout</a> should always be used.
|
||||
<p>This function can be used to verify that all packets have been flushed. If the return value is 0, all packets have been placed into a page.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_pageout(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct, which represents the current logical bitstream.</dd>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to a page of data. The remaining packets in the stream will be placed into this page, if any remain.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>0 means that all packet data has already been flushed into pages, and there are no packets to put into the page.</li>
|
||||
<li>
|
||||
Nonzero means that remaining packets have successfully been flushed into the page.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,66 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_init</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_init</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to initialize an <a href="ogg_sync_state.html">ogg_stream_state</a> struct and allocates appropriate memory in preparation for encoding or decoding.
|
||||
<p>It also assigns the stream a given serial number.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_init(<a href="ogg_stream_state.html">ogg_stream_state</a> *os,int serialno);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the ogg_stream_state struct that we will be initializing.</dd>
|
||||
<dt><i>serialno</i></dt>
|
||||
<dd>Serial number that we will attach to this stream.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 if successful</li>
|
||||
<li>
|
||||
-1 if unsuccessful. If this fails, the ogg_stream_state was not properly declared before calling this function.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_packetin</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_packetin</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function takes a packet and submits it to the bitstream. After this is called, we can continue submitting packets, or we can write out pages.
|
||||
<p>In a typical decoding situation, this should be used after filling a packet with data
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_packetin(ogg_stream_state *os,ogg_packet *op);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct.</dd>
|
||||
<dt><i>op</i></dt>
|
||||
<dd>Pointer to the packet we are putting into the bitstream.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,68 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_packetout</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_packetout</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function assembles a raw data packet for output to the codec decoding engine. The data is already in the stream and broken into packet segments.</p>
|
||||
<p>In a typical decoding situation, this should be used after calling <a href="ogg_stream_pagein.html">ogg_stream_pagein()</a> to submit a page of data to the bitstream.</p>
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to a previously declared <a
|
||||
href="ogg_stream_state.html">ogg_stream_state</a> struct. Before this function is called, an <a href="ogg_page.html">ogg_page</a> should be submitted to the stream using <a href="ogg_stream_pagein.html">ogg_stream_pagein()</a>.</dd>
|
||||
<dt><i>op</i></dt>
|
||||
<dd>Pointer to the packet that will be submitted to the decoding layer after this function is called.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>-1 if we are out of sync and there is a gap in the data. Usually this will not be a fatal error.</li>
|
||||
<li>1 in all other cases.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
|
||||
<br><br>
|
||||
|
||||
<hr noshade>
|
||||
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,85 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_packetpeek</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg version 1.26 - 20010527</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_packetout</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function attempts to assemble a raw data packet and returns
|
||||
it without advancing decoding.</p>
|
||||
|
||||
<p>In a typical situation, this would be called
|
||||
speculatively after <a
|
||||
href="ogg_stream_pagein.html">ogg_stream_pagein()</a> to check
|
||||
the packet contents before handing it off to a codec for
|
||||
decompression. To advance page decoding and remove
|
||||
the packet from the sync structure, call
|
||||
<a href="ogg_stream_packetout.html">ogg_stream_packetout()</a>.</p>
|
||||
|
||||
<br><br>
|
||||
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_packetpeek(ogg_stream_state *os,ogg_packet *op);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to a previously declared
|
||||
<a href="ogg_stream_state.html">ogg_stream_state</a> struct. Before this
|
||||
function is called, an <a href="ogg_page.html">ogg_page</a> should be
|
||||
submitted to the stream using
|
||||
<a href="ogg_stream_pagein.html">ogg_stream_pagein()</a>.</dd>
|
||||
<dt><i>op</i></dt>
|
||||
<dd>Pointer to the next packet available in the bitstream, if
|
||||
any. A NULL value may be passed in the case of a simple "is there a
|
||||
packet?" check.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>-1 if there's no packet available due to lost sync or a hole
|
||||
in the data.</li>
|
||||
<li>1 if a packet is available.</li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
|
||||
|
||||
<br><br>
|
||||
|
||||
<hr noshade>
|
||||
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2001 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg version 1.26 - 20010527</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,67 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_pagein</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_pagein</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function adds a complete page to the bitstream.
|
||||
<p>In a typical decoding situation, this function would be called after using <a href="ogg_sync_pageout.html">ogg_sync_pageout</a> to create a valid <a href="ogg_page.html">ogg_page</a> struct.
|
||||
<p>Internally, this function breaks the page into packet segments in preparation for outputting a valid packet to the codec decoding layer.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_pagein(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_stream.html">ogg_stream</a> struct, which represents the current logical bitstream.</dd>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to a page of data. The data inside this page is being submitted to the streaming layer in order to be allocated into packets.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>-1 indicates failure. This means that the serial number of the page did not match the serial number of the bitstream, or that the page version was incorrect.</li>
|
||||
<li>
|
||||
0 means that the page was successfully submitted to the bitstream.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,67 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_pageout</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_pageout</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function forms packets into pages. If
|
||||
<p>In a typical encoding situation, this would be called after using <a href="ogg_stream_packetin.html">ogg_stream_packetin</a> to submit data packets to the bitstream.
|
||||
<p>Internally, this function breaks the page into packet segments in preparation for outputting a valid packet to the codec decoding layer.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_pageout(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_stream.html">ogg_stream</a> struct, which represents the current logical bitstream.</dd>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to a page of data. The data inside this page is being submitted to the streaming layer in order to be allocated into packets.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>0 means that there is not enough data yet to form a page.</li>
|
||||
<li>
|
||||
0 means that the page was successfully submitted to the bitstream.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,61 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_reset</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_reset</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function sets values in the <a href="ogg_sync_state.html">ogg_stream_state</a> struct back to initial values.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_reset(ogg_stream_state *os);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the ogg_stream_state struct to be cleared.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,67 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_stream_reset</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_reset</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function reinitializes the values in the
|
||||
<a href="ogg_stream_state.html">ogg_stream_state</a>,
|
||||
just like <a href="ogg_stream_reset.html">ogg_stream_reset()</a>.
|
||||
Additionally, it sets the stream serial number to the given value.</p>
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_stream_reset(ogg_stream_state *os, int serialno);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>os</i></dt>
|
||||
<dd>Pointer to the ogg_stream_state struct to be cleared.</dd>
|
||||
<dt><i>serialno</i></dt>
|
||||
<dd>New stream serial number to use</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,121 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - datatype - ogg_stream_state</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_stream_state</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h"</i></p>
|
||||
|
||||
<p>
|
||||
The ogg_stream_state struct tracks the current encode/decode state of the current logical bitstream.
|
||||
<p>
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
typedef struct {
|
||||
unsigned char *body_data; /* bytes from packet bodies */
|
||||
long body_storage; /* storage elements allocated */
|
||||
long body_fill; /* elements stored; fill mark */
|
||||
long body_returned; /* elements of fill returned */
|
||||
|
||||
|
||||
int *lacing_vals; /* The values that will go to the segment table */
|
||||
ogg_int64_t *granule_vals; /* granulepos values for headers. Not compact
|
||||
this way, but it is simple coupled to the
|
||||
lacing fifo */
|
||||
long lacing_storage;
|
||||
long lacing_fill;
|
||||
long lacing_packet;
|
||||
long lacing_returned;
|
||||
|
||||
unsigned char header[282]; /* working space for header encode */
|
||||
int header_fill;
|
||||
|
||||
int e_o_s; /* set when we have buffered the last packet in the
|
||||
logical bitstream */
|
||||
int b_o_s; /* set after we've written the initial page
|
||||
of a logical bitstream */
|
||||
long serialno;
|
||||
int pageno;
|
||||
ogg_int64_t packetno; /* sequence number for decode; the framing
|
||||
knows where there's a hole in the data,
|
||||
but we need coupling so that the codec
|
||||
(which is in a seperate abstraction
|
||||
layer) also knows about the gap */
|
||||
ogg_int64_t granulepos;
|
||||
|
||||
} ogg_stream_state;
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Relevant Struct Members</h3>
|
||||
<dl>
|
||||
<dt><i>body_data</i></dt>
|
||||
<dd>Pointer to data from packet bodies.</dd>
|
||||
<dt><i>body_storage</i></dt>
|
||||
<dd>Storage allocated for bodies in bytes (filled or unfilled).</dd>
|
||||
<dt><i>body_fill</i></dt>
|
||||
<dd>Amount of storage filled with stored packet bodies.</dd>
|
||||
<dt><i>body_returned</i></dt>
|
||||
<dd>Number of elements returned from storage.</dd>
|
||||
<dt><i>lacing_vals</i></dt>
|
||||
<dd>String of lacing values for the packet segments within the current page. Each value is a byte, indicating packet segment length.</dd>
|
||||
<dt><i>granule_vals</i></dt>
|
||||
<dd>Pointer to the lacing values for the packet segments within the current page.</dd>
|
||||
<dt><i>lacing_storage</i></dt>
|
||||
<dd>Total amount of storage (in bytes) allocated for storing lacing values.</dd>
|
||||
<dt><i>lacing_fill</i></dt>
|
||||
<dd>Fill marker for the current vs. total allocated storage of lacing values for the page.</dd>
|
||||
<dt><i>lacing_packet</i></dt>
|
||||
<dd>Lacing value for current packet segment.</dd>
|
||||
<dt><i>lacing_returned</i></dt>
|
||||
<dd>Number of lacing values returned from lacing_storage.</dd>
|
||||
<dt><i>header</i></dt>
|
||||
<dd>Temporary storage for page header during encode process, while the header is being created.</dd>
|
||||
<dt><i>header_fill</i></dt>
|
||||
<dd>Fill marker for header storage allocation. Used during the header creation process.</dd>
|
||||
<dt><i>e_o_s</i></dt>
|
||||
<dd>Marker set when the last packet of the logical bitstream has been buffered.</dd>
|
||||
<dt><i>b_o_s</i></dt>
|
||||
<dd>Marker set after we have written the first page in the logical bitstream.</dd>
|
||||
<dt><i>serialno</i></dt>
|
||||
<dd>Serial number of this logical bitstream.</dd>
|
||||
<dt><i>pageno</i></dt>
|
||||
<dd>Number of the current page within the stream.</dd>
|
||||
<dt><i>packetno</i></dt>
|
||||
<dd>Number of the current packet.</dd>
|
||||
<dt><i>granulepos</i></dt>
|
||||
<dd>Exact position of decoding/encoding process.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,67 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_buffer</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_buffer</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to provide a properly-sized buffer for writing.
|
||||
<p>Buffer space which has already been returned is cleared, and the buffer is extended as necessary by the size plus some additional bytes. Within the current implementation, an extra 4096 bytes are allocated, but applications should not rely on this additional buffer space.
|
||||
<p>The buffer exposed by this function is empty internal storage from the <a href="ogg_sync_state.html">ogg_sync_state</a> struct, beginning at the fill mark within the struct.
|
||||
<p>A pointer to this buffer is returned to be used by the calling application.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
char *ogg_sync_buffer(ogg_sync_state *oy, long size);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
|
||||
<dt><i>size</i></dt>
|
||||
<dd>Size of the desired buffer. The actual size of the buffer returned will be this size plus some extra bytes (currently 4096).
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
Returns a pointer to the newly allocated buffer.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_clear</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_clear</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to free the internal storage of an <a href="ogg_sync_state.html">ogg_sync_state</a> struct and resets the struct to the initial state. To free the entire struct, <a href="ogg_sync_destroy.html">ogg_sync_destroy</a> should be used instead. In situations where the struct needs to be reset but the internal storage does not need to be freed, <a href="ogg_sync_reset.html">ogg_sync_reset</a> should be used.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_clear(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_destroy</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_destroy</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to destroy an <a href="ogg_sync_state.html">ogg_sync_state</a> struct and free all memory used.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_destroy(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_init</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_init</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to initialize an <a href="ogg_sync_state.html">ogg_sync_state</a> struct to a known initial value in preparation for manipulation of an Ogg bitstream.
|
||||
<p>The ogg_sync struct is important when decoding, as it synchronizes retrieval and return of data.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_init(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct. After this function call, this struct has been initialized.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,79 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_pageout</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_pageout</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function takes the data stored in the buffer of the <a href="ogg_sync_state.html">ogg_sync_state</a> struct and inserts them into an <a href="ogg_page.html">ogg_page</a>.
|
||||
|
||||
<p>In an actual decoding loop, this function should be called first to ensure that the buffer is cleared. The example code below illustrates a clean reading loop which will fill and output pages.
|
||||
<p><b>Caution:</b>This function should be called before reading into the buffer to ensure that data does not remain in the ogg_sync_state struct. Failing to do so may result in a memory leak. See the example code below for details.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_pageout(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy, <a href="ogg_page.html">ogg_page</a> *og);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct. Normally, the internal storage of this struct should be filled with newly read data and verified using <a href="ogg_sync_wrote.html">ogg_sync_wrote</a>.</dd>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to page struct filled by this function.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>-1 if we were not properly synced and had to skip some bytes.</li>
|
||||
<li>
|
||||
0 if we need more data to verify a page.</li>
|
||||
<li>
|
||||
1 if we have a page.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<h3>Example Usage</h3>
|
||||
<pre>
|
||||
if (ogg_sync_pageout(&oy, &og) != 1) {
|
||||
buffer = ogg_sync_buffer(&oy, 8192);
|
||||
bytes = fread(buffer, 1, 8192, stdin);
|
||||
ogg_sync_wrote(&oy, bytes);
|
||||
}
|
||||
</pre>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,68 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_pageseek</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_pageseek</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function synchronizes the ogg_sync_state struct to the next ogg_page.
|
||||
<p>This is useful when seeking within a bitstream. ogg_sync_pageseek will synchronize to the next page in the bitstream and return information about how many bytes we advanced or skipped in order to do so.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_pageseek(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy, <a href="ogg_page.html">ogg_page</a> *og);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
|
||||
<dt><i>og</i></dt>
|
||||
<dd>Pointer to a page (or an incomplete page) of data. This is the page we are attempting to sync.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>-n means that we skipped n bytes within the bitstream.</li>
|
||||
<li>
|
||||
0 means that the page isn't ready and we need more data. No bytes have been skipped.</li>
|
||||
<li>
|
||||
n means that the page was synced at the current location, with a page length of n bytes.
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_reset</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_reset</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to reset the internal counters of the <a href="ogg_sync_state.html">ogg_sync_state</a> struct to initial values.
|
||||
<p>It is a good idea to call this before seeking within a bitstream.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_reset(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
0 is always returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,67 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - datatype - ogg_sync_state</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_state</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h"</i></p>
|
||||
|
||||
<p>
|
||||
The ogg_sync_state struct tracks the synchronization of the current page.
|
||||
<p>It is used during decoding to track the status of data as it is read in and
|
||||
<p>
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
typedef struct {
|
||||
unsigned char *data;
|
||||
int storage;
|
||||
int fill;
|
||||
int returned;
|
||||
|
||||
int unsynced;
|
||||
int headerbytes;
|
||||
int bodybytes;
|
||||
} ogg_sync_state;
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Relevant Struct Members</h3>
|
||||
<dl>
|
||||
<dt><i>data</i></dt>
|
||||
<dd>Pointer to data from packet bodies.</dd>
|
||||
<dt><i>storage</i></dt>
|
||||
<dd>Pointer to data from packet bodies.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - ogg_sync_wrote</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>ogg_sync_wrote</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function is used to tell the <a href="ogg_sync_state.html">ogg_sync_state</a> struct how many bytes we wrote into the buffer.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
int ogg_sync_destroy(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>oy</i></dt>
|
||||
<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>-1 if the number of bytes written overflows the internal storage of the <a href="ogg_sync_state.html">ogg_sync_state</a> struct.
|
||||
<li>
|
||||
0 in all other cases.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,64 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_adv</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_adv</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function advances the location pointer by the specified number of bits without reading any data.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_adv(oggpack_buffer *b,int bits);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to the current oggpack_buffer.</dd>
|
||||
<dt><i>bits</i></dt>
|
||||
<dd>Number of bits to advance.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_adv1</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_adv1</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function advances the location pointer by one bit without reading any data.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_adv1(oggpack_buffer *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to the current oggpack_buffer.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>No values are returned.
|
||||
</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_bits</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_bits</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function returns the total number of bits currently in the <a href="oggpack_buffer.html">oggpack_buffer</a>'s internal buffer.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
long oggpack_bits(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd><a href="oggpack_buffer.html">oggpack_buffer</a> struct to be .</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the total number of bits within the current buffer.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,66 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - datatype - oggpack_buffer</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_buffer</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h"</i></p>
|
||||
|
||||
<p>
|
||||
The oggpack_buffer struct is used with libogg's bitpacking functions. You should never need to directly access anything in this structure.
|
||||
<p>
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
typedef struct {
|
||||
long endbyte;
|
||||
int endbit;
|
||||
|
||||
unsigned char *buffer;
|
||||
unsigned char *ptr;
|
||||
long storage;
|
||||
} oggpack_buffer;
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Relevant Struct Members</h3>
|
||||
<dl>
|
||||
<dt><i>buffer</i></dt>
|
||||
<dd>Pointer to data being manipulated.</dd>
|
||||
<dt><i>ptr</i></dt>
|
||||
<dd>Location pointer to mark which data has been read.</dd>
|
||||
<dt><i>storage</i></dt>
|
||||
<dd>Size of buffer.</i></dt>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_bytes</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_bytes</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function returns the total number of bytes currently in the <a href="oggpack_buffer.html">oggpack_buffer</a>'s internal buffer.
|
||||
<p>The return value is the number of <b>complete</b> bytes in the buffer. There may be extra (<8) bits.
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
long oggpack_bytes(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd><a href="oggpack_buffer.html">oggpack_buffer</a> struct to be checked.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the total number of bytes within the current buffer.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_get_buffer</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_get_buffer</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function returns a pointer to the data buffer within the given <a href="oggpack_buffer.html">oggpack_buffer</a> struct.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
unsigned char *oggpack_get_buffer(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to the current <a href="oggpack_buffer.html">oggpack_buffer</a>.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,66 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_look</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_look</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function looks at a specified number of bits inside the buffer without advancing the location pointer.
|
||||
<p>The specified number of bits are read, starting from the location pointer.
|
||||
<p>This function can be used to read 32 or fewer bits.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
long oggpack_look(<a href="oggpack_buffer.html">oggpack_buffer</a> *b,int bits);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to <a href="oggpack_buffer.html">oggpack_buffer</a> to be read.</dd>
|
||||
<dt><i>bits</i></dt>
|
||||
<dd>Number of bits to look at. For this function, must be 32 or fewer.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> represents the requested bits.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_look1</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_look1</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function looks at the next bit without advancing the location pointer.
|
||||
<p>The next bit is read starting from the location pointer.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
long oggpack_look1(oggpack_buffer *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to an <a href="oggpack_buffer.html">oggpack_buffer</a> struct containing our buffer.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> represents the value of the next bit after the location pointer.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_read</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_read</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function reads the requested number of bits from the buffer and advances the location pointer.
|
||||
<p>Before reading, the buffer should be initialized using <a href="oggpack_readinit.html">oggpack_readinit</a>.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
long oggpack_read(oggpack_buffer *b,int bits);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to an <a href="oggpack_buffer.html">oggpack_buffer</a> struct containing buffered data to be read.</dd>
|
||||
<dt><i>bits</i></dt>
|
||||
<dd>Number of bits to read.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> represents the requested bits.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,63 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_read1</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_read1</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function reads one bit from the <a href="oggpack_buffer.html">oggpack_buffer</a> data buffer and advances the location pointer.
|
||||
<p>Before reading, the buffer should be initialized using <a href="oggpack_readinit.html">oggpack_readinit</a>.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
long oggpack_read1(oggpack_buffer *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to an <a href="oggpack_buffer.html">oggpack_buffer</a> struct containing buffered data to be read.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
<i>n</i> is the bit read by this function.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,64 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_readinit</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_readinit</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function takes an ordinary buffer and prepares an <a href="oggpack_buffer.html">oggpack_buffer</a> for reading using the Ogg <a href="bitpacking.html">bitpacking</a> functions.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Pointer to <a href=oggpack_buffer.html">oggpack_buffer</a> to be initialized with some extra markers to ease bit navigation and manipulation.</dd>
|
||||
<dt><i>buf</i></dt>
|
||||
<dd>Original data buffer, to be inserted into the <a href="oggpack_buffer.html">oggpack_buffer</a> so that it can be read using bitpacking functions.
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_reset</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_reset</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function resets the contents of an <a href="oggpack_buffer">oggpack_buffer</a> to their original state but does not free the memory used.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_reset(oggpack_buffer *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd><a href="oggpack_buffer.html">oggpack_buffer</a> to be reset.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,68 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_write</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_write</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function writes bits into an <a href="oggpack_buffer.html">oggpack_buffer</a>.
|
||||
<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.
|
||||
<p>Only 32 bits can be written at a time.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_write(oggpack_buffer *b,unsigned long value,int bits);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Buffer to be used for writing.</dd>
|
||||
<dt><i>value</i></dt>
|
||||
<dd>The data to be written into the buffer. This must be 32 bits or fewer.</dd>
|
||||
<dt><i>bits</i></dt>
|
||||
<dd>The number of bits being written into the buffer.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_writealign</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_writealign</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function pads the <a href="oggpack_buffer.html">oggpack_buffer</a> with zeros out to the
|
||||
next byte boundary.</p>
|
||||
<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.
|
||||
<p>Only 32 bits can be written at a time.</p>
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_writetrunc(oggpack_buffer *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Buffer to be used for writing.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_reset</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_writeclear</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function clears the buffer after writing and frees the memory used by the oggpack_buffer.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_writeclear(oggpack_buffer *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Our oggpack_buffer. This is an ordinary data buffer with some extra markers to ease bit navigation and manipulation.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,69 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_writecopy</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_writecopy</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function copies a sequence of bits from a source buffer into an
|
||||
<a href="oggpack_buffer.html">oggpack_buffer</a>.</p>
|
||||
<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.</p>
|
||||
<p>Only 32 bits can be written at a time.</p>
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_writecopy(oggpack_buffer *b, void *source, long bits);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Buffer to be used for writing.</dd>
|
||||
<dt><i>source</i></dt>
|
||||
<dd>A pointer to the data to be written into the buffer.</dd>
|
||||
<dt><i>bits</i></dt>
|
||||
<dd>The number of bits to be copied into the buffer.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,62 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_writeinit</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_writeinit</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function initializes an <a href="oggpack_buffer.html">oggpack_buffer</a> for writing using the Ogg <a href="bitpacking.html">bitpacking</a> functions.
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_writeinit(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Buffer to be used for writing. This is an ordinary data buffer with some extra markers to ease bit navigation and manipulation.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,65 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - function - oggpack_writetrunc</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>oggpack_write</h1>
|
||||
|
||||
<p><i>declared in "ogg/ogg.h";</i></p>
|
||||
|
||||
<p>This function truncates an already written-to <a href="oggpack_buffer.html">oggpack_buffer</a>.</p>
|
||||
<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.</p>
|
||||
|
||||
<br><br>
|
||||
<table border=0 color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>
|
||||
void oggpack_writetrunc(oggpack_buffer *b, long bits);
|
||||
</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>b</i></dt>
|
||||
<dd>Buffer to be truncated.</dd>
|
||||
<dt><i>bits</i></dt>
|
||||
<dd>Number of bits to keep in the buffer (size after truncation)</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<h3>Return Values</h3>
|
||||
<blockquote>
|
||||
<li>
|
||||
No values are returned.</li>
|
||||
</blockquote>
|
||||
<p>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,44 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>libogg - API Overview</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Libogg API Overview</h1>
|
||||
|
||||
<p>
|
||||
The libogg API consists of the following functional categories:
|
||||
<p>
|
||||
<ul>
|
||||
<li><p><a href="datastructures.html">Base data structures</a>
|
||||
<li><p><a href="bitpacking.html">Bitpacking</a>
|
||||
<li><p><a href="general.html">General</a>
|
||||
<li><p><a href="encoding.html">Encoding-Related</a>
|
||||
<li><p><a href="decoding.html">Decoding-Related</a>
|
||||
|
||||
</ul>
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2000 xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg release 1.0 - 20000615</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,93 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Libogg API Reference</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>Libogg API Reference</h1>
|
||||
|
||||
<p>
|
||||
<b>Data Structures</b><br>
|
||||
<a href="oggpack_buffer.html">oggpack_buffer</a><br>
|
||||
<a href="ogg_page.html">ogg_page</a><br>
|
||||
<a href="ogg_stream_state.html">ogg_stream_state</a><br>
|
||||
<a href="ogg_packet.html">ogg_packet</a><br>
|
||||
<a href="ogg_sync_state.html">ogg_sync_state</a><br>
|
||||
<br>
|
||||
<b>Bitpacking</b><br>
|
||||
<a href="oggpack_writeinit.html">oggpack_writeinit()</a><br>
|
||||
<a href="oggpack_reset.html">oggpack_reset()</a><br>
|
||||
<a href="oggpack_writeclear.html">oggpack_writetrunc()</a><br>
|
||||
<a href="oggpack_writeclear.html">oggpack_writealign()</a><br>
|
||||
<a href="oggpack_writeclear.html">oggpack_writecopy()</a><br>
|
||||
<a href="oggpack_writeclear.html">oggpack_writeclear()</a><br>
|
||||
<a href="oggpack_readinit.html">oggpack_readinit()</a><br>
|
||||
<a href="oggpack_write.html">oggpack_write()</a><br>
|
||||
<a href="oggpack_look.html">oggpack_look()</a><br>
|
||||
<a href="oggpack_look1.html">oggpack_look1()</a><br>
|
||||
<a href="oggpack_adv.html">oggpack_adv()</a><br>
|
||||
<a href="oggpack_adv1.html">oggpack_adv1()</a><br>
|
||||
<a href="oggpack_read.html">oggpack_read()</a><br>
|
||||
<a href="oggpack_read1.html">oggpack_read1()</a><br>
|
||||
<a href="oggpack_bytes.html">oggpack_bytes()</a><br>
|
||||
<a href="oggpack_bits.html">oggpack_bits()</a><br>
|
||||
<a href="oggpack_get_buffer.html">oggpack_get_buffer()</a><br>
|
||||
<br>
|
||||
<b>Decoding-Related</b><br>
|
||||
<a href="ogg_sync_init.html">ogg_sync_init()</a><br>
|
||||
<a href="ogg_sync_clear.html">ogg_sync_clear()</a><br>
|
||||
<a href="ogg_sync_destroy.html">ogg_sync_destroy()</a><br>
|
||||
<a href="ogg_sync_reset.html">ogg_sync_reset()</a><br>
|
||||
<a href="ogg_sync_buffer.html">ogg_sync_buffer()</a><br>
|
||||
<a href="ogg_sync_wrote.html">ogg_sync_wrote()</a><br>
|
||||
<a href="ogg_sync_pageseek.html">ogg_sync_pageseek()</a><br>
|
||||
<a href="ogg_sync_pageout.html">ogg_sync_pageout()</a><br>
|
||||
<a href="ogg_stream_pagein.html">ogg_stream_pagein()</a><br>
|
||||
<a href="ogg_stream_packetout.html">ogg_stream_packetout()</a><br>
|
||||
<a href="ogg_stream_packetpeek.html">ogg_stream_packetpeek()</a><br>
|
||||
<br>
|
||||
<b>Encoding-Related</b><br>
|
||||
<a href="ogg_stream_packetin.html">ogg_stream_packetin()</a><br>
|
||||
<a href="ogg_stream_pageout.html">ogg_stream_pageout()</a><br>
|
||||
<a href="ogg_stream_flush.html">ogg_stream_flush()</a><br>
|
||||
<br>
|
||||
<b>General</b><br>
|
||||
<a href="ogg_stream_init.html">ogg_stream_init()</a><br>
|
||||
<a href="ogg_stream_clear.html">ogg_stream_clear()</a><br>
|
||||
<a href="ogg_stream_reset.html">ogg_stream_reset()</a><br>
|
||||
<a href="ogg_stream_reset_serialno.html">ogg_stream_reset_serialno()</a><br>
|
||||
<a href="ogg_stream_destroy.html">ogg_stream_destroy()</a><br>
|
||||
<a href="ogg_page_version.html">ogg_page_version()</a><br>
|
||||
<a href="ogg_page_continued.html">ogg_page_continued()</a><br>
|
||||
<a href="ogg_page_packets.html">ogg_page_packets()</a></br>
|
||||
<a href="ogg_page_bos.html">ogg_page_bos()</a><br>
|
||||
<a href="ogg_page_eos.html">ogg_page_eos()</a><br>
|
||||
<a href="ogg_page_granulepos.html">ogg_page_granulepos()</a><br>
|
||||
<a href="ogg_page_serialno.html">ogg_page_serialno()</a><br>
|
||||
<a href="ogg_page_pageno.html">ogg_page_pageno()</a><br>
|
||||
<a href="ogg_packet_clear.html">ogg_packet_clear()</a><br>
|
||||
<a href="ogg_page_checksum_set.html">ogg_page_checksum_set()</a><br>
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/index.html">Ogg Vorbis</a><br><a href="mailto:[email protected]">[email protected]</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>libogg documentation</p></td>
|
||||
<td align=right><p class=tiny>libogg - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,7 @@
|
||||
BODY { font-family: Helvetica, sans-serif }
|
||||
TD { font-family: Helvetica, sans-serif }
|
||||
P { font-family: Helvetica, sans-serif }
|
||||
H1 { font-family: Helvetica, sans-serif }
|
||||
H2 { font-family: Helvetica, sans-serif }
|
||||
H4 { font-family: Helvetica, sans-serif }
|
||||
P.tiny { font-size: 8pt }
|
||||
@@ -0,0 +1,70 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Vorbisfile - datatype - vorbis_comment</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>Vorbisfile documentation</p></td>
|
||||
<td align=right><p class=tiny>libVorbisfile version 1.65 - 20020702</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>vorbis_comment</h1>
|
||||
|
||||
<p><i>declared in "vorbis/codec.h"</i></p>
|
||||
|
||||
<p>
|
||||
The vorbis_comment structure defines an Ogg Vorbis comment.
|
||||
<p>
|
||||
Only the fields the program needs must be defined. If a field isn't
|
||||
defined by the application, it will either be blank (if it's a string value)
|
||||
or set to some reasonable default (usually 0).
|
||||
<p>
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>typedef struct vorbis_comment{
|
||||
/* unlimited user comment fields. */
|
||||
char **user_comments;
|
||||
int *comment_lengths;
|
||||
int comments;
|
||||
char *vendor;
|
||||
|
||||
} vorbis_comment;</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Parameters</h3>
|
||||
<dl>
|
||||
<dt><i>user_comments</i></dt>
|
||||
<dd>Unlimited user comment array. The individual strings in the array are 8 bit clean, by the Vorbis specification, and as such the <tt>comment_lengths</tt> array should be consulted to determine string length. For convenience, each string is also NULL-terminated by the decode library (although Vorbis comments are not NULL terminated within the bitstream itself).</dd>
|
||||
<dt><i>comment_lengths</i></dt>
|
||||
<dd>An array that stores the length of each comment string</dd>
|
||||
<dt><i>comments</i></dt>
|
||||
<dd>number of user comments in user_comments field.</dd>
|
||||
<dt><i>vendor</i></dt>
|
||||
<dd>Information about the creator of the file. Stored in a standard C 0-terminated string.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org Foundation</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>Vorbisfile documentation</p></td>
|
||||
<td align=right><p class=tiny>libVorbisfile version 1.65 - 20020719</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,80 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Vorbisfile - datatype - vorbis_info</title>
|
||||
<link rel=stylesheet href="style.css" type="text/css">
|
||||
</head>
|
||||
|
||||
<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
|
||||
<table border=0 width=100%>
|
||||
<tr>
|
||||
<td><p class=tiny>Vorbisfile documentation</p></td>
|
||||
<td align=right><p class=tiny>libVorbisfile version 1.65 - 20020702</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h1>vorbis_info</h1>
|
||||
|
||||
<p><i>declared in "vorbis/codec.h"</i></p>
|
||||
|
||||
<p>
|
||||
The vorbis_info structure contains basic information about the audio in a vorbis bitstream.
|
||||
<p>
|
||||
|
||||
<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
|
||||
<tr bgcolor=#cccccc>
|
||||
<td>
|
||||
<pre><b>typedef struct vorbis_info{
|
||||
int version;
|
||||
int channels;
|
||||
long rate;
|
||||
|
||||
long bitrate_upper;
|
||||
long bitrate_nominal;
|
||||
long bitrate_lower;
|
||||
long bitrate_window;
|
||||
|
||||
void *codec_setup;
|
||||
|
||||
} vorbis_info;</b></pre>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<h3>Relevant Struct Members</h3>
|
||||
<dl>
|
||||
<dt><i>version</i></dt>
|
||||
<dd>Vorbis encoder version used to create this bitstream.</dd>
|
||||
<dt><i>channels</i></dt>
|
||||
<dd>Int signifying number of channels in bitstream.</dd>
|
||||
<dt><i>rate</i></dt>
|
||||
<dd>Sampling rate of the bitstream.</dd>
|
||||
<dt><i>bitrate_upper</i></dt>
|
||||
<dd>Specifies the upper limit in a VBR bitstream. If the value matches the bitrate_nominal and bitrate_lower parameters, the stream is fixed bitrate. May be unset if no limit exists.</dd>
|
||||
<dt><i>bitrate_nominal</i></dt>
|
||||
<dd>Specifies the average bitrate for a VBR bitstream. May be unset. If the bitrate_upper and bitrate_lower parameters match, the stream is fixed bitrate.</dd>
|
||||
<dt><i>bitrate_lower</i></dt>
|
||||
<dd>Specifies the lower limit in a VBR bitstream. If the value matches the bitrate_nominal and bitrate_upper parameters, the stream is fixed bitrate. May be unset if no limit exists.</dd>
|
||||
<dt><i>bitrate_window</i></dt>
|
||||
<dd>Currently unset.</dd>
|
||||
|
||||
<dt><i>codec_setup</i></dt>
|
||||
<dd>Internal structure that contains the detailed/unpacked configuration for decoding the current Vorbis bitstream.</dd>
|
||||
</dl>
|
||||
|
||||
|
||||
<br><br>
|
||||
<hr noshade>
|
||||
<table border=0 width=100%>
|
||||
<tr valign=top>
|
||||
<td><p class=tiny>copyright © 2002 Xiph.org</p></td>
|
||||
<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/vorbis/">Ogg Vorbis</a></p></td>
|
||||
</tr><tr>
|
||||
<td><p class=tiny>Vorbisfile documentation</p></td>
|
||||
<td align=right><p class=tiny>libVorbisfile version 1.65 - 20020702</p></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,196 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
|
||||
src="vorbisword2.png" border=0></a></nobr><p>
|
||||
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg logical and physical bitstream overview
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 14, 2002</em><br>
|
||||
|
||||
<h2>Ogg bitstreams</h2>
|
||||
|
||||
Ogg codecs use octet vectors of raw, compressed data
|
||||
(<em>packets</em>). 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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h2>Logical and physical bitstreams</h2>
|
||||
|
||||
Raw packets are grouped and encoded into contiguous pages of
|
||||
structured bitstream data called <em>logical bitstreams</em>. 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.<p>
|
||||
|
||||
Multiple logical bitstreams can be combined (with restrictions) into a
|
||||
single <em>physical bitstream</em>. 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'. <p>
|
||||
|
||||
<a href=framing.html>Ogg Logical Bitstream Framing</a> 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.<p>
|
||||
|
||||
<h2>Mapping Restrictions</h2>
|
||||
|
||||
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 '<a href="vorbis-ogg.html">Ogg Vorbis
|
||||
Audio Bitstream</a>', for example, has a <a
|
||||
href="vorbis-ogg.html">specific physical bitstream structure</a>.
|
||||
An 'Ogg A/V' bitstream (not currently specified) will also mandate a
|
||||
specific, restricted physical bitstream format.<p>
|
||||
|
||||
<h3>additional end-to-end structure</h3>
|
||||
|
||||
The <a href="framing.html">framing specification</a> 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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h3>sequential multiplexing (chaining)</h3>
|
||||
|
||||
The simplest form of logical bitstream multiplexing is concatenation
|
||||
(<em>chaining</em>). 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.<p>
|
||||
|
||||
Each chained logical bitstream must have a unique serial number within
|
||||
the scope of the physical bitstream.<p>
|
||||
|
||||
<h3>concurrent multiplexing (grouping)</h3>
|
||||
|
||||
Logical bitstreams may also be multiplexed 'in parallel'
|
||||
(<em>grouped</em>). 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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
Each grouped bitstream must have a unique serial number within the
|
||||
scope of the physical bitstream.<p>
|
||||
|
||||
<h3>sequential and concurrent multiplexing</h3>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h3>multiplexing example</h3>
|
||||
|
||||
Below, we present an example of a grouped and chained bitstream:<p>
|
||||
|
||||
<img src=stream.png><p>
|
||||
|
||||
In this example, we see pages from five total logical bitstreams
|
||||
multiplexed into a physical bitstream. Note the following
|
||||
characteristics:
|
||||
|
||||
<ol><li>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.<p>
|
||||
|
||||
<li>The pages of concurrently multiplexed bitstreams need not conform
|
||||
to a regular order; the only requirement is that page <tt>n</tt> of a
|
||||
logical bitstream follow page <tt>n-1</tt> 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).
|
||||
|
||||
</ol>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 2.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 965 B |
@@ -0,0 +1,54 @@
|
||||
## Process this with automake to create Makefile.in
|
||||
|
||||
AUTOMAKE_OPTIONS = foreign
|
||||
|
||||
SUBDIRS = vorbisfile vorbisenc
|
||||
|
||||
docdir = $(datadir)/doc/$(PACKAGE)-$(VERSION)
|
||||
|
||||
doc_DATA = components.png \
|
||||
draft-moffitt-vorbis-rtp-00.txt \
|
||||
eightphase.png \
|
||||
evenlsp.png \
|
||||
floor1-1.png \
|
||||
floor1-2.png \
|
||||
floor1-3.png \
|
||||
floor1-4.png \
|
||||
floor1_inverse_dB_table.html \
|
||||
floorval.png \
|
||||
fourphase.png \
|
||||
framing.html \
|
||||
helper.html \
|
||||
hufftree-under.png \
|
||||
hufftree.png \
|
||||
index.html \
|
||||
lspmap.png \
|
||||
oddlsp.png \
|
||||
oggstream.html \
|
||||
programming.html \
|
||||
residue-pack.png \
|
||||
residue2.png \
|
||||
squarepolar.png \
|
||||
stereo.html \
|
||||
stream.png \
|
||||
v-comment.html \
|
||||
vorbis-clip.txt \
|
||||
vorbis-errors.txt \
|
||||
vorbis-fidelity.html \
|
||||
vorbis-ogg.html \
|
||||
vorbis-spec-bitpack.html \
|
||||
vorbis-spec-codebook.html \
|
||||
vorbis-spec-floor0.html \
|
||||
vorbis-spec-floor1.html \
|
||||
vorbis-spec-intro.html \
|
||||
vorbis-spec-ref.html \
|
||||
vorbis-spec-res.html \
|
||||
vorbis.html \
|
||||
vorbisword2.png \
|
||||
wait.png \
|
||||
white-ogg.png \
|
||||
white-xifish.png \
|
||||
window1.png \
|
||||
window2.png
|
||||
|
||||
EXTRA_DIST = $(doc_DATA)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
@@ -0,0 +1,230 @@
|
||||
Network Working Group Jack Moffitt
|
||||
Internet-Draft Xiph.org Foundation
|
||||
Expire in six months February 2001
|
||||
|
||||
|
||||
RTP Payload Format for Vorbis Encoded Audio
|
||||
|
||||
<draft-moffitt-vorbis-rtp-00.txt>
|
||||
|
||||
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.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a RTP payload format for transporting Vorbis
|
||||
encoded audio.
|
||||
|
||||
1 Introduction
|
||||
|
||||
This document describes how Vorbis encoded audio may be formatted for
|
||||
use as an RTP payload type.
|
||||
|
||||
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 RFC 2119 [1].
|
||||
|
||||
2 Background
|
||||
|
||||
The Xiph.org Foundation creates and defines codecs for use in
|
||||
multimedia that are not encumbered by patents and thus may be freely
|
||||
implemented by any individual or organization.
|
||||
|
||||
Vorbis is the general purpose multi-channel audio codec created by
|
||||
the Xiph.org Foundation.
|
||||
|
||||
Vorbis encoded audio is generally found within an Ogg format
|
||||
bitstream, which provides framing and synchronization. For the
|
||||
purposes of RTP transport, this layer is unnecessary, and so raw
|
||||
Vorbis packets are used in the payload.
|
||||
|
||||
Vorbis packets are unbounded in length currently. At some future
|
||||
point there will likely be a practical limit placed on packet
|
||||
length.
|
||||
|
||||
Typical Vorbis packet sizes are from very small (2-3 bytes) to
|
||||
quite large (8-12 kilobytes). The reference implementation seems to
|
||||
make every packet less than ~800 bytes, except for the codebooks
|
||||
packet which is ~8-12 kilobytes.
|
||||
|
||||
3 Payload Format
|
||||
|
||||
The standard RTP header is followed by an 8 bit payload header, and
|
||||
the payload data.
|
||||
|
||||
3.1 RTP Header
|
||||
|
||||
The following fields of the RTP header are used for Vorbis payloads:
|
||||
|
||||
Payload Type (PT): 7 bits
|
||||
An RTP profile for a class of applications is expected to assign a
|
||||
payload type for this format, or a dynamically allocated payload
|
||||
type should be chosen which designates the payload as Vorbis.
|
||||
|
||||
Timestamp: 32 bits
|
||||
A timestamp representing the sampling time of the first sample of
|
||||
the first Vorbis packet in the RTP packet. The clock frequency
|
||||
MUST be set to the sample rate of the encoded audio data and is
|
||||
conveyed out-of-band.
|
||||
|
||||
Marker (M): 1 bit
|
||||
Set to one if the payload contains complete packets or if it
|
||||
contains the last fragment of a fragmented packet.
|
||||
|
||||
3.2 Payload Header
|
||||
|
||||
The first byte of the payload data is the payload header:
|
||||
|
||||
+---+---+---+---+---+---+---+---+
|
||||
| C | R | R | # of packets |
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|
||||
C: 1 bit
|
||||
Set to one if this is a continuation of a fragmented packet.
|
||||
|
||||
R: 1 bit x 2
|
||||
Reserved, must be set to zero by senders, and ignored by
|
||||
receivers.
|
||||
|
||||
The last 5 bits are the number of complete packets in this payload.
|
||||
If C is set to one, this number should be 0.
|
||||
|
||||
3.3 Payload Data
|
||||
|
||||
If the payload contains a single Vorbis packet or a Vorbis packet
|
||||
fragment, the Vorbis packet data follows the payload header.
|
||||
|
||||
For payloads which consist of multiple Vorbis packets, payload data
|
||||
consists of one byte representing the packet length followed by the
|
||||
packet data for each of the Vorbis packets in the payload.
|
||||
|
||||
The Vorbis packet length byte is the length minus one. A value of
|
||||
0 means a length of 1.
|
||||
|
||||
3.4 Example RTP Packet
|
||||
|
||||
Here is an example RTP packet containing two Vorbis packets.
|
||||
|
||||
RTP Packet Header:
|
||||
|
||||
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 8 0 1
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|V=2|P|X| CC |M| PT | sequence number |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| timestamp (in sample rate units) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| sychronization source (SSRC) identifier |
|
||||
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
||||
| contributing source (CSRC) identifiers |
|
||||
| ... |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
Payload Data:
|
||||
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|0|0|0| # pks: 2| len | vorbis data ... |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| ...vorbis data... |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| ... | len | next vorbis packet data... |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
4 Frame Packetizing
|
||||
|
||||
Each RTP packet contains either one complete Vorbis packet, one
|
||||
Vorbis packet fragment, or an integer number of complete Vorbis
|
||||
packets (a max of 32 packets, since the number of packets is
|
||||
defined by a 5 bit value).
|
||||
|
||||
Any Vorbis packet that is larger than 256 bytes and less than the
|
||||
path-MTU should be placed in a RTP packet by itself.
|
||||
|
||||
Any Vorbis packet that is 256 bytes or less should be bundled in the
|
||||
RTP packet with as many Vorbis packets as will fit, up to a maximum
|
||||
of 32.
|
||||
|
||||
If a packet will not fit into the RTP packet, it must be fragmented.
|
||||
A fragmented packet has a zero in the last five bits of the payload
|
||||
header. Each fragment after the first will also set the Continued
|
||||
(C) bit to one in the payload header. The RTP packet containing the
|
||||
last fragment of the Vorbis packet will have the Marker (M) bit set
|
||||
to one.
|
||||
|
||||
5 Open Issues
|
||||
|
||||
To decode a Vorbis stream, a set of codebooks is required. These
|
||||
codebooks are allowed to change for each logical bitstream (for
|
||||
example, for each song encoded in a radio stream).
|
||||
|
||||
The codebooks must be completely intact and a client can not decode
|
||||
a stream with an incomplete or corrupted set.
|
||||
|
||||
A client connecting to a multicast RTP Vorbis session needs to get the
|
||||
first set of codebooks in some manner. These codebooks are typically
|
||||
between 4 kilobytes and 8 kilobytes in size.
|
||||
|
||||
A final solution to how best to deliver the codebooks has not yet been
|
||||
realized. Here are the current proposals:
|
||||
|
||||
- Including the first set of codebooks in the SDP description
|
||||
|
||||
- Broadcasting a codebook only stream as a second multicast Vorbis
|
||||
stream
|
||||
|
||||
- Create some method of requesting the codebooks via RTCP
|
||||
|
||||
- Periodically retransmit the headers inline
|
||||
|
||||
6 Security Considerations
|
||||
|
||||
RTP packets using this payload format are subject to the security
|
||||
considerations discussed in the RTP specification [1]. This implies
|
||||
that the confidentiality of the media stream is achieved by using
|
||||
encryption. Becase the data compression used with this payload
|
||||
format is applied end-to-end, encryption may be performed on the
|
||||
compressed data.
|
||||
|
||||
7 Acknowledgements
|
||||
|
||||
Thanks to the rest of the Xiph.org team, especially Monty
|
||||
<[email protected]>. Thanks also to Rob Lanphier <[email protected]> for
|
||||
his guidance.
|
||||
|
||||
8 References
|
||||
|
||||
1. RTP: A Transport Protocol for Real-Time Applications (RFC 1889)
|
||||
|
||||
2. Xiph.org's Ogg Vorbis pages http://www.xiph.org/ogg/vorbis/
|
||||
Vorbis documentation only currently exists as API documenation,
|
||||
or as source code. The source can be obtained at
|
||||
http://www.xiph.org/ogg/vorbis/download.html
|
||||
|
||||
9 Author's Address
|
||||
|
||||
Jack Moffitt
|
||||
Executive Director
|
||||
Xiph.org Foundation
|
||||
email: [email protected]
|
||||
WWW: http://www.xiph.org/
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.8 KiB |
@@ -0,0 +1,112 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg Vorbis I format specification: floor1_inverse_dB_table
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 18, 2002</em><p>
|
||||
|
||||
The vector <tt>[floor1_inverse_dB_table]</tt> is a 256 element static
|
||||
lookup table consiting of the following values (read left to right
|
||||
then top to bottom):
|
||||
|
||||
<pre>
|
||||
1.0649863e-07, 1.1341951e-07, 1.2079015e-07, 1.2863978e-07,
|
||||
1.3699951e-07, 1.4590251e-07, 1.5538408e-07, 1.6548181e-07,
|
||||
1.7623575e-07, 1.8768855e-07, 1.9988561e-07, 2.1287530e-07,
|
||||
2.2670913e-07, 2.4144197e-07, 2.5713223e-07, 2.7384213e-07,
|
||||
2.9163793e-07, 3.1059021e-07, 3.3077411e-07, 3.5226968e-07,
|
||||
3.7516214e-07, 3.9954229e-07, 4.2550680e-07, 4.5315863e-07,
|
||||
4.8260743e-07, 5.1396998e-07, 5.4737065e-07, 5.8294187e-07,
|
||||
6.2082472e-07, 6.6116941e-07, 7.0413592e-07, 7.4989464e-07,
|
||||
7.9862701e-07, 8.5052630e-07, 9.0579828e-07, 9.6466216e-07,
|
||||
1.0273513e-06, 1.0941144e-06, 1.1652161e-06, 1.2409384e-06,
|
||||
1.3215816e-06, 1.4074654e-06, 1.4989305e-06, 1.5963394e-06,
|
||||
1.7000785e-06, 1.8105592e-06, 1.9282195e-06, 2.0535261e-06,
|
||||
2.1869758e-06, 2.3290978e-06, 2.4804557e-06, 2.6416497e-06,
|
||||
2.8133190e-06, 2.9961443e-06, 3.1908506e-06, 3.3982101e-06,
|
||||
3.6190449e-06, 3.8542308e-06, 4.1047004e-06, 4.3714470e-06,
|
||||
4.6555282e-06, 4.9580707e-06, 5.2802740e-06, 5.6234160e-06,
|
||||
5.9888572e-06, 6.3780469e-06, 6.7925283e-06, 7.2339451e-06,
|
||||
7.7040476e-06, 8.2047000e-06, 8.7378876e-06, 9.3057248e-06,
|
||||
9.9104632e-06, 1.0554501e-05, 1.1240392e-05, 1.1970856e-05,
|
||||
1.2748789e-05, 1.3577278e-05, 1.4459606e-05, 1.5399272e-05,
|
||||
1.6400004e-05, 1.7465768e-05, 1.8600792e-05, 1.9809576e-05,
|
||||
2.1096914e-05, 2.2467911e-05, 2.3928002e-05, 2.5482978e-05,
|
||||
2.7139006e-05, 2.8902651e-05, 3.0780908e-05, 3.2781225e-05,
|
||||
3.4911534e-05, 3.7180282e-05, 3.9596466e-05, 4.2169667e-05,
|
||||
4.4910090e-05, 4.7828601e-05, 5.0936773e-05, 5.4246931e-05,
|
||||
5.7772202e-05, 6.1526565e-05, 6.5524908e-05, 6.9783085e-05,
|
||||
7.4317983e-05, 7.9147585e-05, 8.4291040e-05, 8.9768747e-05,
|
||||
9.5602426e-05, 0.00010181521, 0.00010843174, 0.00011547824,
|
||||
0.00012298267, 0.00013097477, 0.00013948625, 0.00014855085,
|
||||
0.00015820453, 0.00016848555, 0.00017943469, 0.00019109536,
|
||||
0.00020351382, 0.00021673929, 0.00023082423, 0.00024582449,
|
||||
0.00026179955, 0.00027881276, 0.00029693158, 0.00031622787,
|
||||
0.00033677814, 0.00035866388, 0.00038197188, 0.00040679456,
|
||||
0.00043323036, 0.00046138411, 0.00049136745, 0.00052329927,
|
||||
0.00055730621, 0.00059352311, 0.00063209358, 0.00067317058,
|
||||
0.00071691700, 0.00076350630, 0.00081312324, 0.00086596457,
|
||||
0.00092223983, 0.00098217216, 0.0010459992, 0.0011139742,
|
||||
0.0011863665, 0.0012634633, 0.0013455702, 0.0014330129,
|
||||
0.0015261382, 0.0016253153, 0.0017309374, 0.0018434235,
|
||||
0.0019632195, 0.0020908006, 0.0022266726, 0.0023713743,
|
||||
0.0025254795, 0.0026895994, 0.0028643847, 0.0030505286,
|
||||
0.0032487691, 0.0034598925, 0.0036847358, 0.0039241906,
|
||||
0.0041792066, 0.0044507950, 0.0047400328, 0.0050480668,
|
||||
0.0053761186, 0.0057254891, 0.0060975636, 0.0064938176,
|
||||
0.0069158225, 0.0073652516, 0.0078438871, 0.0083536271,
|
||||
0.0088964928, 0.009474637, 0.010090352, 0.010746080,
|
||||
0.011444421, 0.012188144, 0.012980198, 0.013823725,
|
||||
0.014722068, 0.015678791, 0.016697687, 0.017782797,
|
||||
0.018938423, 0.020169149, 0.021479854, 0.022875735,
|
||||
0.024362330, 0.025945531, 0.027631618, 0.029427276,
|
||||
0.031339626, 0.033376252, 0.035545228, 0.037855157,
|
||||
0.040315199, 0.042935108, 0.045725273, 0.048696758,
|
||||
0.051861348, 0.055231591, 0.058820850, 0.062643361,
|
||||
0.066714279, 0.071049749, 0.075666962, 0.080584227,
|
||||
0.085821044, 0.091398179, 0.097337747, 0.10366330,
|
||||
0.11039993, 0.11757434, 0.12521498, 0.13335215,
|
||||
0.14201813, 0.15124727, 0.16107617, 0.17154380,
|
||||
0.18269168, 0.19456402, 0.20720788, 0.22067342,
|
||||
0.23501402, 0.25028656, 0.26655159, 0.28387361,
|
||||
0.30232132, 0.32196786, 0.34289114, 0.36517414,
|
||||
0.38890521, 0.41417847, 0.44109412, 0.46975890,
|
||||
0.50028648, 0.53279791, 0.56742212, 0.60429640,
|
||||
0.64356699, 0.68538959, 0.72993007, 0.77736504,
|
||||
0.82788260, 0.88168307, 0.9389798, 1.
|
||||
<pre>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
@@ -0,0 +1,395 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
|
||||
src="vorbisword2.png" border=0></a></nobr><p>
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg logical bitstream framing
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 14, 2002</em><br>
|
||||
|
||||
<h2>Ogg bitstreams</h2>
|
||||
|
||||
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 Tarkin video codec.
|
||||
|
||||
<h2>Application example: Vorbis</h2>
|
||||
Vorbis encodes short-time blocks of PCM data into raw packets of
|
||||
bit-packed data. These 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 uses 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.<p>
|
||||
|
||||
<h2>Design constraints for Ogg bitstreams</h2>
|
||||
|
||||
<ol><li>True streaming; we must not need to seek to build a 100%
|
||||
complete bitstream.
|
||||
|
||||
<li> Use no more than approximately 1-2% of bitstream bandwidth for
|
||||
packet boundary marking, high-level framing, sync and seeking.
|
||||
|
||||
<li> Specification of absolute position within the original sample
|
||||
stream.
|
||||
|
||||
<li> Simple mechanism to ease limited editing, such as a simplified
|
||||
concatenation mechanism.
|
||||
|
||||
<li> Detection of corruption, recapture after error and direct, random
|
||||
access to data at arbitrary positions in the bitstream.
|
||||
</ol>
|
||||
|
||||
<h2>Logical and Physical Bitstreams</h2>
|
||||
|
||||
A <em>logical</em> Ogg bitstream is a contiguous stream of
|
||||
sequential pages belonging only to the logical bitstream. A
|
||||
<em>physical</em> Ogg bitstream is constructed from one or more
|
||||
than one logical Ogg bitstream (the simplest physical bitstream
|
||||
is simply a single logical bitstream). We describe below the exact
|
||||
formatting of an Ogg logical bitstream. Combining logical
|
||||
bitstreams into more complex physical bitstreams is described in the
|
||||
<a href="oggstream.html">Ogg bitstream overview</a>. The exact
|
||||
mapping of raw Vorbis packets into a valid Ogg Vorbis physical
|
||||
bitstream is described in <a href="vorbis-stream.html">Vorbis
|
||||
bitstream mapping</a>.
|
||||
|
||||
<h2>Bitstream structure</h2>
|
||||
|
||||
An Ogg stream is structured by dividing incoming packets into
|
||||
segments of up to 255 bytes and then wrapping a group of contiguous
|
||||
packet segments into a variable length page preceded by a page
|
||||
header. Both the header size and page size are variable; the page
|
||||
header contains sizing information and checksum data to determine
|
||||
header/page size and data integrity.<p>
|
||||
|
||||
The bitstream is captured (or recaptured) by looking for the beginning
|
||||
of a page, specifically the capture pattern. Once the capture pattern
|
||||
is found, the decoder verifies page sync and integrity by computing
|
||||
and comparing the checksum. At that point, the decoder can extract the
|
||||
packets themselves.<p>
|
||||
|
||||
<h3>Packet segmentation</h3>
|
||||
|
||||
Packets are logically divided into multiple segments before encoding
|
||||
into a page. Note that the segmentation and fragmentation process is a
|
||||
logical one; it's used to compute page header values and the original
|
||||
page data need not be disturbed, even when a packet spans page
|
||||
boundaries.<p>
|
||||
|
||||
The raw packet is logically divided into [n] 255 byte segments and a
|
||||
last fractional segment of < 255 bytes. A packet size may well
|
||||
consist only of the trailing fractional segment, and a fractional
|
||||
segment may be zero length. These values, called "lacing values" are
|
||||
then saved and placed into the header segment table.<p>
|
||||
|
||||
An example should make the basic concept clear:<p>
|
||||
|
||||
<pre>
|
||||
<tt>
|
||||
raw packet:
|
||||
___________________________________________
|
||||
|______________packet data__________________| 753 bytes
|
||||
|
||||
lacing values for page header segment table: 255,255,243
|
||||
</tt>
|
||||
</pre>
|
||||
|
||||
We simply add the lacing values for the total size; the last lacing
|
||||
value for a packet is always the value that is less than 255. Note
|
||||
that this encoding both avoids imposing a maximum packet size as well
|
||||
as imposing minimum overhead on small packets (as opposed to, eg,
|
||||
simply using two bytes at the head of every packet and having a max
|
||||
packet size of 32k. Small packets (<255, the typical case) are
|
||||
penalized with twice the segmentation overhead). Using the lacing
|
||||
values as suggested, small packets see the minimum possible
|
||||
byte-aligned overheade (1 byte) and large packets, over 512 bytes or
|
||||
so, see a fairly constant ~.5% overhead on encoding space.<p>
|
||||
|
||||
Note that a lacing value of 255 implies that a second lacing value
|
||||
follows in the packet, and a value of < 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:<p>
|
||||
|
||||
<pre><tt>
|
||||
raw packet:
|
||||
_______________________________
|
||||
|________packet data____________| 255 bytes
|
||||
|
||||
lacing values: 255, 0
|
||||
</tt></pre>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h3>Packets spanning pages</h3>
|
||||
|
||||
Packets are not restricted to beginning and ending within a page,
|
||||
although individual segments are, by definition, required to do so.
|
||||
Packets are not restricted to a maximum size, although excessively
|
||||
large packets in the data stream are discouraged; the Ogg
|
||||
bitstream specification strongly recommends nominal page size of
|
||||
approximately 4-8kB (large packets are foreseen as being useful for
|
||||
initialization data at the beginning of a logical bitstream).<p>
|
||||
|
||||
After segmenting a packet, the encoder may decide not to place all the
|
||||
resulting segments into the current page; to do so, the encoder places
|
||||
the lacing values of the segments it wishes to belong to the current
|
||||
page into the current segment table, then finishes the page. The next
|
||||
page is begun with the first value in the segment table belonging to
|
||||
the next packet segment, thus continuing the packet (data in the
|
||||
packet body must also correspond properly to the lacing values in the
|
||||
spanned pages. The segment data in the first packet corresponding to
|
||||
the lacing values of the first page belong in that page; packet
|
||||
segments listed in the segment table of the following page must begin
|
||||
the page body of the subsequent page).<p>
|
||||
|
||||
The last mechanic to spanning a page boundary is to set the header
|
||||
flag in the new page to indicate that the first lacing value in the
|
||||
segment table continues rather than begins a packet; a header flag of
|
||||
0x01 is set to indicate a continued packet. Although mandatory, it
|
||||
is not actually algorithmically necessary; one could inspect the
|
||||
preceding segment table to determine if the packet is new or
|
||||
continued. Adding the information to the packet_header flag allows a
|
||||
simpler design (with no overhead) that needs only inspect the current
|
||||
page header after frame capture. This also allows faster error
|
||||
recovery in the event that the packet originates in a corrupt
|
||||
preceding page, implying that the previous page's segment table
|
||||
cannot be trusted.<p>
|
||||
|
||||
Note that a packet can span an arbitrary number of pages; the above
|
||||
spanning process is repeated for each spanned page boundary. Also a
|
||||
'zero termination' on a packet size that is an even multiple of 255
|
||||
must appear even if the lacing value appears in the next page as a
|
||||
zero-length continuation of the current packet. The header flag
|
||||
should be set to 0x01 to indicate that the packet spanned, even though
|
||||
the span is a nil case as far as data is concerned.<p>
|
||||
|
||||
The encoding looks odd, but is properly optimized for speed and the
|
||||
expected case of the majority of packets being between 50 and 200
|
||||
bytes (note that it is designed such that packets of wildly different
|
||||
sizes can be handled within the model; placing packet size
|
||||
restrictions on the encoder would have only slightly simplified design
|
||||
in page generation and increased overall encoder complexity).<p>
|
||||
|
||||
The main point behind tracking individual packets (and packet
|
||||
segments) is to allow more flexible encoding tricks that requiring
|
||||
explicit knowledge of packet size. An example is simple bandwidth
|
||||
limiting, implemented by simply truncating packets in the nominal case
|
||||
if the packet is arranged so that the least sensitive portion of the
|
||||
data comes last.<p>
|
||||
|
||||
<h3>Page header</h3>
|
||||
|
||||
The headering mechanism is designed to avoid copying and re-assembly
|
||||
of the packet data (ie, making the packet segmentation process a
|
||||
logical one); the header can be generated directly from incoming
|
||||
packet data. The encoder buffers packet data until it finishes a
|
||||
complete page at which point it writes the header followed by the
|
||||
buffered packet segments.<p>
|
||||
|
||||
<h4>capture_pattern</h4>
|
||||
|
||||
A header begins with a capture pattern that simplifies identifying
|
||||
pages; once the decoder has found the capture pattern it can do a more
|
||||
intensive job of verifying that it has in fact found a page boundary
|
||||
(as opposed to an inadvertent coincidence in the byte stream).<p>
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
0 0x4f 'O'
|
||||
1 0x67 'g'
|
||||
2 0x67 'g'
|
||||
3 0x53 'S'
|
||||
</tt></pre>
|
||||
|
||||
<h4>stream_structure_version</h4>
|
||||
|
||||
The capture pattern is followed by the stream structure revision:
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
4 0x00
|
||||
</tt></pre>
|
||||
|
||||
<h4>header_type_flag</h4>
|
||||
|
||||
The header type flag identifies this page's context in the bitstream:
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
5 bitflags: 0x01: unset = fresh packet
|
||||
set = continued packet
|
||||
0x02: unset = not first page of logical bitstream
|
||||
set = first page of logical bitstream (bos)
|
||||
0x04: unset = not last page of logical bitstream
|
||||
set = last page of logical bitstream (eos)
|
||||
</tt></pre>
|
||||
|
||||
<h4>absolute granule position</h4>
|
||||
|
||||
(This is packed in the same way the rest of Ogg data is packed; LSb
|
||||
of LSB first. Note that the 'position' data specifies a 'sample'
|
||||
number (eg, in a CD quality sample is four octets, 16 bits for left
|
||||
and 16 bits for right; in video it would likely be the frame number.
|
||||
It is up to the specific codec in use to define the semantic meaning
|
||||
of the granule position value). The position specified is the total
|
||||
samples encoded after including all packets finished on this page
|
||||
(packets begun on this page but continuing on to the next page do not
|
||||
count). The rationale here is that the position specified in the
|
||||
frame header of the last page tells how long the data coded by the
|
||||
bitstream is. A truncated stream will still return the proper number
|
||||
of samples that can be decoded fully.
|
||||
<p>
|
||||
A special value of '-1' (in two's complement) indicates that no packets
|
||||
finish on this page.
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
6 0xXX LSB
|
||||
7 0xXX
|
||||
8 0xXX
|
||||
9 0xXX
|
||||
10 0xXX
|
||||
11 0xXX
|
||||
12 0xXX
|
||||
13 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>stream serial number</h4>
|
||||
|
||||
Ogg allows for separate logical bitstreams to be mixed at page
|
||||
granularity in a physical bitstream. The most common case would be
|
||||
sequential arrangement, but it is possible to interleave pages for
|
||||
two separate bitstreams to be decoded concurrently. The serial
|
||||
number is the means by which pages physical pages are associated with
|
||||
a particular logical stream. Each logical stream must have a unique
|
||||
serial number within a physical stream:
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
14 0xXX LSB
|
||||
15 0xXX
|
||||
16 0xXX
|
||||
17 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>page sequence no</h4>
|
||||
|
||||
Page counter; lets us know if a page is lost (useful where packets
|
||||
span page boundaries).
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
18 0xXX LSB
|
||||
19 0xXX
|
||||
20 0xXX
|
||||
21 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>page checksum</h4>
|
||||
|
||||
32 bit CRC value (direct algorithm, initial val and final XOR = 0,
|
||||
generator polynomial=0x04c11db7). The value is computed over the
|
||||
entire header (with the CRC field in the header set to zero) and then
|
||||
continued over the page. The CRC field is then filled with the
|
||||
computed value.<p>
|
||||
|
||||
(A thorough discussion of CRC algorithms can be found in <a
|
||||
href="ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt">"A
|
||||
Painless Guide to CRC Error Detection Algorithms"</a> by Ross
|
||||
Williams <a
|
||||
href="mailto:[email protected]">[email protected]</a>.)
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
22 0xXX LSB
|
||||
23 0xXX
|
||||
24 0xXX
|
||||
25 0xXX MSB
|
||||
</tt></pre>
|
||||
|
||||
<h4>page_segments</h4>
|
||||
|
||||
The number of segment entries to appear in the segment table. The
|
||||
maximum number of 255 segments (255 bytes each) sets the maximum
|
||||
possible physical page size at 65307 bytes or just under 64kB (thus
|
||||
we know that a header corrupted so as destroy sizing/alignment
|
||||
information will not cause a runaway bitstream. We'll read in the
|
||||
page according to the corrupted size information that's guaranteed to
|
||||
be a reasonable size regardless, notice the checksum mismatch, drop
|
||||
sync and then look for recapture).<p>
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
26 0x00-0xff (0-255)
|
||||
</tt></pre>
|
||||
|
||||
<h4>segment_table (containing packet lacing values)</h4>
|
||||
|
||||
The lacing values for each packet segment physically appearing in
|
||||
this page are listed in contiguous order.
|
||||
|
||||
<pre><tt>
|
||||
byte value
|
||||
|
||||
27 0x00-0xff (0-255)
|
||||
[...]
|
||||
n 0x00-0xff (0-255, n=page_segments+26)
|
||||
</tt></pre>
|
||||
|
||||
Total page size is calculated directly from the known header size and
|
||||
lacing values in the segment table. Packet data segments follow
|
||||
immediately after the header.<p>
|
||||
|
||||
Page headers typically impose a flat .25-.5% space overhead assuming
|
||||
nominal ~8k page sizes. The segmentation table needed for exact
|
||||
packet recovery in the streaming layer adds approximately .5-1%
|
||||
nominal assuming expected encoder behavior in the 44.1kHz, 128kbps
|
||||
stereo encodings.<p>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
|
||||
@@ -0,0 +1,196 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg Vorbis I format specification: helper equations
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 18, 2002</em><p>
|
||||
|
||||
<h1>Overview</h1>
|
||||
|
||||
The equations below are used in multiple places by the Vorbis codec
|
||||
specification. Rather than cluttering up the main specification
|
||||
documents, they are defined here and linked int he main documents
|
||||
where appropriate.<p>
|
||||
|
||||
<a name=log><h2>ilog</h2></a>
|
||||
|
||||
|
||||
The "ilog(x)" function returns the highest set bit in the two's complement integer value
|
||||
<tt>[x]</tt>. Values of <tt>[x]</tt> less than zero are defined to return zero.
|
||||
|
||||
<pre>
|
||||
1) [return_value] = 0;
|
||||
2) if ( [x] is greater than nonzero ){
|
||||
|
||||
3) increment [return_value];
|
||||
4) logical shift [x] one bit to the right, padding the MSb with zero
|
||||
5) repeat at step 2)
|
||||
|
||||
}
|
||||
|
||||
6) done
|
||||
</pre>
|
||||
|
||||
Examples:
|
||||
|
||||
<ul><li> ilog(0) = 0;
|
||||
<li> ilog(1) = 1;
|
||||
<li> ilog(2) = 2;
|
||||
<li> ilog(3) = 2;
|
||||
<li> ilog(4) = 3;
|
||||
<li> ilog(7) = 3;
|
||||
<li> ilog(negative number) = 0;
|
||||
</uL>
|
||||
|
||||
<a name=float32_unpack><h2>float32_unpack</h2></a>
|
||||
|
||||
"float32_unpack(x)" is intended to translate the packed binary
|
||||
representation of a Vorbis codebook float value into the
|
||||
representation used by the decoder for floating point numbers. For
|
||||
purposes of this example, we will unpack a Vorbis float32 into a
|
||||
host-native floating point number.<p>
|
||||
|
||||
<pre>
|
||||
1) [mantissa] = [x] bitwise AND 0x1fffff (unsigned result)
|
||||
2) [sign] = [x] bitwise AND 0x80000000 (unsigned result)
|
||||
3) [exponent] = ( [x] bitwise AND 0x7fe00000) shifted left 21 bits (unsigned result)
|
||||
4) if ( [mantissa] is nonzero ) then negate [mantissa]
|
||||
5) return [mantissa] * ( 2 ^ ( [exponent] - 788 ) )
|
||||
</pre>
|
||||
|
||||
<a name=lookup1_values><h2>lookup1_values</h2></a>
|
||||
|
||||
"lookup1_values(codebook_entries,codebook_dimensions)" is used to
|
||||
compute the correct length of the value index for a codebook VQ lookup
|
||||
table of lookup type 1. The values on this list are permuted to
|
||||
construct the VQ vector lookup table of size
|
||||
<tt>[codebook_entries]</tt>.<p>
|
||||
|
||||
The return value for this function is defined to be 'the greatest
|
||||
integer value for which <tt>[return_value] to the power of
|
||||
[codebook_dimensions] is less than or equal to
|
||||
[codebook_entries]</tt>'.
|
||||
|
||||
<a name=low_neighbor><h2>low_neighbor</h2></a>
|
||||
|
||||
"low_neighbor(v,x)" finds the position <i>n</i> in vector [v] of
|
||||
the greatest value scalar element for which <i>n</i> is less than
|
||||
<tt>[x]</tt> and <tt>vector [v] element <i>n</i> is less
|
||||
than vector [v] element [x]</tt>.
|
||||
|
||||
<a name=high_neighbor><h2>high_neighbor</h2></a>
|
||||
|
||||
"high_neighbor(v,x)" finds the position <i>n</i> in vector [v] of
|
||||
the lowest value scalar element for which <i>n</i> is less than
|
||||
<tt>[x]</tt> and <tt>vector [v] element <i>n</i> is greater
|
||||
than vector [v] element [x]</tt>.
|
||||
|
||||
<a name=render_point><h2>render_point</h2></a>
|
||||
|
||||
"render_point(x0,x1,y0,y1,X)" is used to find the Y value at point X
|
||||
along the line specified by x0, x1, y0 and y1. This function uses an
|
||||
integer algorithm to solve for the point directly without calculating
|
||||
intervening values along the line.<p>
|
||||
|
||||
<pre>
|
||||
1) [dy] = [y1] - [y0]
|
||||
2) [adx] = [x1] - [x0]
|
||||
3) [ady] = absolute value of [dy]
|
||||
4) [err] = [ady] * ([X] - [x0])
|
||||
5) [off] = [err] / [adx] using integer division
|
||||
6) if ( [dy] is less than zero ) {
|
||||
|
||||
7) [Y] = [y0] - [off]
|
||||
|
||||
} else {
|
||||
|
||||
8) [Y] = [y0] + [off]
|
||||
|
||||
}
|
||||
|
||||
9) done
|
||||
</pre>
|
||||
|
||||
<a name=render_line><h2>render_line</h2></a>
|
||||
|
||||
Floor decode type one uses the integer line drawing algorithm of
|
||||
"render_line(x0, y0, x1, y1, v)" to construct an integer floor
|
||||
curve for contiguous piecewise line segments. Note that it has not
|
||||
been relevant elsewhere, but here we must define integer division as
|
||||
rounding division of both positive and negative numbers toward zero.
|
||||
|
||||
<pre>
|
||||
1) [dy] = [y1] - [y0]
|
||||
2) [adx] = [x1] - [x0]
|
||||
3) [ady] = absolute value of [dy]
|
||||
4) [base] = [dy] / [adx] using integer division
|
||||
5) [x] = [x0]
|
||||
6) [y] = [y0]
|
||||
7) [err] = 0
|
||||
|
||||
8) if ( [dy] is less than 0 ) {
|
||||
|
||||
9) [sy] = [base] - 1
|
||||
|
||||
} else {
|
||||
|
||||
10) [sy] = [base] + 1
|
||||
|
||||
}
|
||||
|
||||
11) [ady] = [ady] - [base] * [adx]
|
||||
12) vector [v] element [x] = [y]
|
||||
|
||||
13) iterate [x] over the range [x0]+1 ... [x1]-1 {
|
||||
|
||||
14) [err] = [err] + [ady];
|
||||
15) if ( [err] >= [adx] ) {
|
||||
|
||||
15) [err] = [err] - [adx]
|
||||
16) [y] = [y] + [sy]
|
||||
|
||||
} else {
|
||||
|
||||
17) [y] = [y] + [base]
|
||||
|
||||
}
|
||||
|
||||
18) vector [v] element [x] = [y]
|
||||
|
||||
}
|
||||
</pre>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 KiB |
@@ -0,0 +1,79 @@
|
||||
<title> xiph.org: Ogg Vorbis documentation </title>
|
||||
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg Vorbis Documentation
|
||||
</font></h1>
|
||||
|
||||
<em>Last documentation revision: July 16, 2002</em><p>
|
||||
|
||||
<h2>Vorbis technical discussion documents</h2>
|
||||
<ul>
|
||||
<li><a href="vorbis-fidelity.html">Fidelity measurement terminology</a>
|
||||
<li><a href="stereo.html">Vorbis channel coupling and stereo-specific application</a>
|
||||
</ul>
|
||||
|
||||
<h2>Ogg Vorbis I specification documents</h2>
|
||||
<ul>
|
||||
<li><a href="vorbis-spec-intro.html">Vorbis specification introduction and description</a>
|
||||
<li><a href="vorbis-spec-bitpack.html">Vorbis bitpacking convention</a>
|
||||
<li><a href="vorbis-spec-codebook.html">Vorbis probability model and codebooks</a>
|
||||
<li><a href="vorbis-spec-ref.html">Vorbis codec setup and packet decode</a>
|
||||
<li><a href="v-comment.html">Vorbis comment header specification</a>
|
||||
<li><a href="vorbis-spec-floor0.html">Vorbis floor type 0 setup and decode</a>
|
||||
<li><a href="vorbis-spec-floor1.html">Vorbis floor type 1 setup and decode</a>
|
||||
<li><a href="vorbis-spec-res.html">Vorbis residue types 0, 1 and 2 setup and decode</a>
|
||||
<li><a href="vorbis-ogg.html">Embedding Vorbis encoded audio in an Ogg bitstream</a>
|
||||
<li><a href="draft-moffitt-vorbis-rtp-00.txt">Embedding Vorbis encoded audio in an RTP payload format</a>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2>Ogg Vorbis programming documents</h2>
|
||||
<ul>
|
||||
<li>Programming with libvorbis
|
||||
<li><a href="vorbisfile/index.html">Programming with vorbisfile</a>
|
||||
<li><a href="vorbisenc/index.html">Programming with vorbisenc</a><P>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
<h2>Ogg bitstream documentation</h2>
|
||||
<ul>
|
||||
<li><a href="oggstream.html">Ogg bitstream overview</a>
|
||||
<li><a href="framing.html">Ogg logical bitstream and framing spec</a>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.2 KiB |
@@ -0,0 +1,196 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
|
||||
src="vorbisword2.png" border=0></a></nobr><p>
|
||||
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg logical and physical bitstream overview
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 14, 2002</em><br>
|
||||
|
||||
<h2>Ogg bitstreams</h2>
|
||||
|
||||
Ogg codecs use octet vectors of raw, compressed data
|
||||
(<em>packets</em>). 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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h2>Logical and physical bitstreams</h2>
|
||||
|
||||
Raw packets are grouped and encoded into contiguous pages of
|
||||
structured bitstream data called <em>logical bitstreams</em>. 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.<p>
|
||||
|
||||
Multiple logical bitstreams can be combined (with restrictions) into a
|
||||
single <em>physical bitstream</em>. 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'. <p>
|
||||
|
||||
<a href=framing.html>Ogg Logical Bitstream Framing</a> 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.<p>
|
||||
|
||||
<h2>Mapping Restrictions</h2>
|
||||
|
||||
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 '<a href="vorbis-ogg.html">Ogg Vorbis
|
||||
Audio Bitstream</a>', for example, has a <a
|
||||
href="vorbis-ogg.html">specific physical bitstream structure</a>.
|
||||
An 'Ogg A/V' bitstream (not currently specified) will also mandate a
|
||||
specific, restricted physical bitstream format.<p>
|
||||
|
||||
<h3>additional end-to-end structure</h3>
|
||||
|
||||
The <a href="framing.html">framing specification</a> 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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h3>sequential multiplexing (chaining)</h3>
|
||||
|
||||
The simplest form of logical bitstream multiplexing is concatenation
|
||||
(<em>chaining</em>). 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.<p>
|
||||
|
||||
Each chained logical bitstream must have a unique serial number within
|
||||
the scope of the physical bitstream.<p>
|
||||
|
||||
<h3>concurrent multiplexing (grouping)</h3>
|
||||
|
||||
Logical bitstreams may also be multiplexed 'in parallel'
|
||||
(<em>grouped</em>). 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.<p>
|
||||
|
||||
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.<p>
|
||||
|
||||
Each grouped bitstream must have a unique serial number within the
|
||||
scope of the physical bitstream.<p>
|
||||
|
||||
<h3>sequential and concurrent multiplexing</h3>
|
||||
|
||||
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.<p>
|
||||
|
||||
<h3>multiplexing example</h3>
|
||||
|
||||
Below, we present an example of a grouped and chained bitstream:<p>
|
||||
|
||||
<img src=stream.png><p>
|
||||
|
||||
In this example, we see pages from five total logical bitstreams
|
||||
multiplexed into a physical bitstream. Note the following
|
||||
characteristics:
|
||||
|
||||
<ol><li>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.<p>
|
||||
|
||||
<li>The pages of concurrently multiplexed bitstreams need not conform
|
||||
to a regular order; the only requirement is that page <tt>n</tt> of a
|
||||
logical bitstream follow page <tt>n-1</tt> 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).
|
||||
|
||||
</ol>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
|
||||
@@ -0,0 +1,502 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
||||
|
||||
|
||||
<h1><font color=#000070>
|
||||
Programming with Xiph.org <tt>libvorbis</tt>
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 22, 1999</em><br>
|
||||
|
||||
<h2>Description</h2>
|
||||
|
||||
Libvorbis is the Xiph.org Foundation's portable Ogg Vorbis CODEC
|
||||
implemented as a programmatic library. Libvorbis provides primitives
|
||||
to handle framing and manipulation of Ogg bitstreams (used by the
|
||||
Vorbis for streaming), a full analysis (encoding) interface as well as
|
||||
packet decoding and synthesis for playback. <p>
|
||||
|
||||
The libvorbis library does not provide any system interface; a
|
||||
full-featured demonstration player included with the library
|
||||
distribtion provides example code for a variety of system interfaces
|
||||
as well as a working example of using libvorbis in production code.
|
||||
|
||||
<h2>Encoding Overview</h2>
|
||||
|
||||
|
||||
|
||||
<h2>Decoding Overview</h2>
|
||||
|
||||
Decoding a bitstream with libvorbis follows roughly the following
|
||||
steps:
|
||||
|
||||
<ol>
|
||||
<li>Frame the incoming bitstream into pages
|
||||
<li>Sort the pages by logical bitstream and buffer then into logical streams
|
||||
<li>Decompose the logical streams into raw packets
|
||||
<li>Reconstruct segments of the original data from each packet
|
||||
<li>Glue the reconstructed segments back into a decoded stream
|
||||
</ol>
|
||||
|
||||
<h3>Framing</h3>
|
||||
|
||||
An Ogg bitstream is logically arranged into pages, but to decode
|
||||
the pages, we have to find them first. The raw bitstream is first fed
|
||||
into an <tt>ogg_sync_state</tt> buffer using <tt>ogg_sync_buffer()</tt>
|
||||
and <tt>ogg_sync_wrote()</tt>. After each block we submit to the sync
|
||||
buffer, we should check to see if we can frame and extract a complete
|
||||
page or pages using <tt>ogg_sync_pageout()</tt>. Extra pages are
|
||||
buffered; allowing them to build up in the <tt>ogg_sync_state</tt>
|
||||
buffer will eventually exhaust memory.<p>
|
||||
|
||||
The Ogg pages returned from <tt>ogg_sync_pageout</tt> need not be
|
||||
decoded further to be used as landmarks in seeking; seeking can be
|
||||
either a rough process of simply jumping to approximately intuited
|
||||
portions of the bitstream, or it can be a precise bisection process
|
||||
that captures pages and inspects data position. When seeking,
|
||||
however, sequential multiplexing (chaining) must be accounted for;
|
||||
beginning play in a new logical bitstream requires initializing a
|
||||
synthesis engine with the headers from that bitstream. Vorbis
|
||||
bitstreams do not make use of concurent multiplexing (grouping).<p>
|
||||
|
||||
<h3>Sorting</h3>
|
||||
|
||||
The pages produced by <tt>ogg_sync_pageout</tt> are then sorted by
|
||||
serial number to seperate logical bitstreams. Initialize logical
|
||||
bitstream buffers (<tt>og_stream_state</tt>) using
|
||||
<tt>ogg_stream_init()</tt>. Pages are submitted to the matching
|
||||
logical bitstream buffer using <tt>ogg_stream_pagein</tt>; the serial
|
||||
number of the page and the stream buffer must match, or the page will
|
||||
be rejected. A page submitted out of sequence will simply be noted,
|
||||
and in the course of outputting packets, the hole will be flagged
|
||||
(<tt>ogg_sync_pageout</tt> and <tt>ogg_stream_packetout</tt> will
|
||||
return a negative value at positions where they had to recapture the
|
||||
stream).
|
||||
|
||||
<h3>Extracting packets</h3>
|
||||
|
||||
After submitting page[s] to a logical stream, read available packets
|
||||
using <tt>ogg_stream_packetout</tt>.
|
||||
|
||||
<h3>Decoding packets</h3>
|
||||
|
||||
<h3>Reassembling data segments</h3>
|
||||
|
||||
|
||||
<h2>Ogg Bitstream Manipulation Structures</h3>
|
||||
|
||||
Two of the Ogg bitstream data structures are intended to be
|
||||
transparent to the developer; the fields should be used directly.<p>
|
||||
|
||||
<h3>ogg_packet</h3>
|
||||
|
||||
<pre>
|
||||
typedef struct {
|
||||
unsigned char *packet;
|
||||
long bytes;
|
||||
long b_o_s;
|
||||
long e_o_s;
|
||||
|
||||
size64 granulepos;
|
||||
|
||||
} ogg_packet;
|
||||
</pre>
|
||||
|
||||
<dl>
|
||||
<dt>packet: <dd>a pointer to the byte data of the raw packet
|
||||
<dt>bytes: <dd>the size of the packet' raw data
|
||||
<dt>b_o_s: <dd>beginning of stream; nonzero if this is the first packet of
|
||||
the logical bitstream
|
||||
<dt>e_o_s: <dd>end of stream; nonzero if this is the last packet of the
|
||||
logical bitstream
|
||||
<dt>granulepos: <dd>the absolute position of this packet in the original
|
||||
uncompressed data stream.
|
||||
</dl>
|
||||
|
||||
<h4>encoding notes</h4> The encoder is responsible for setting all of
|
||||
the fields of the packet to appropriate values before submission to
|
||||
<tt>ogg_stream_packetin()</tt>; however, it is noted that the value in
|
||||
<tt>b_o_s</tt> is ignored; the first page produced from a given
|
||||
<tt>ogg_stream_state</tt> structure will be stamped as the initial
|
||||
page. <tt>e_o_s</tt>, however, must be set; this is the means by
|
||||
which the stream encoding primitives handle end of stream and cleanup.
|
||||
|
||||
<h4>decoding notes</h4><tt>ogg_stream_packetout()</tt> sets the fields
|
||||
to appropriate values. Note that granulepos will be >= 0 only in the
|
||||
case that the given packet actually represents that position (ie, only
|
||||
the last packet completed on any page will have a meaningful
|
||||
<tt>granulepos</tt>). Intervening frames will see <tt>granulepos</tt> set
|
||||
to -1.
|
||||
|
||||
<h3>ogg_page</h3>
|
||||
|
||||
<pre>
|
||||
typedef struct {
|
||||
unsigned char *header;
|
||||
long header_len;
|
||||
unsigned char *body;
|
||||
long body_len;
|
||||
} ogg_page;
|
||||
</pre>
|
||||
|
||||
<dl>
|
||||
<dt>header: <dd>pointer to the page header data
|
||||
<dt>header_len: <dd>length of the page header in bytes
|
||||
<dt>body: <dd>pointer to the page body
|
||||
<dt>body_len: <dd>length of the page body
|
||||
</dl>
|
||||
|
||||
Note that although the <tt>header</tt> and <tt>body</tt> pointers do
|
||||
not necessarily point into a single contiguous page vector, the page
|
||||
body must immediately follow the header in the bitstream.<p>
|
||||
|
||||
<h2>Ogg Bitstream Manipulation Functions</h3>
|
||||
|
||||
<h3>
|
||||
int ogg_page_bos(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the 'beginning of stream' flag for the given Ogg page. The
|
||||
beginning of stream flag is set on the initial page of a logical
|
||||
bitstream.<P>
|
||||
|
||||
Zero indicates the flag is cleared (this is not the initial page of a
|
||||
logical bitstream). Nonzero indicates the flag is set (this is the
|
||||
initial page of a logical bitstream).<p>
|
||||
|
||||
<h3>
|
||||
int ogg_page_continued(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the 'packet continued' flag for the given Ogg page. The packet
|
||||
continued flag indicates whether or not the body data of this page
|
||||
begins with packet continued from a preceeding page.<p>
|
||||
Zero (unset) indicates that the body data begins with a new packet.
|
||||
Nonzero (set) indicates that the first packet data on the page is a
|
||||
continuation from the preceeding page.
|
||||
|
||||
<h3>
|
||||
int ogg_page_eos(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the 'end of stream' flag for a give Ogg page. The end of page
|
||||
flag is set on the last (terminal) page of a logical bitstream.<p>
|
||||
|
||||
Zero (unset) indicates that this is not the last page of a logical
|
||||
bitstream. Nonzero (set) indicates that this is the last page of a
|
||||
logical bitstream and that no addiitonal pages belonging to this
|
||||
bitstream may follow.<p>
|
||||
|
||||
<h3>
|
||||
size64 ogg_page_granulepos(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the position of this page as an absolute position within the
|
||||
original uncompressed data. The position, as returned, is 'frames
|
||||
encoded to date up to and including the last whole packet on this
|
||||
page'. Partial packets begun on this page but continued to the
|
||||
following page are not included. If no packet ends on this page, the
|
||||
frame position value will be equal to the frame position value of the
|
||||
preceeding page. If none of the original uncompressed data is yet
|
||||
represented in the logical bitstream (for example, the first page of a
|
||||
bitstream consists only of a header packet; this packet encodes only
|
||||
metadata), the value shall be zero.<p>
|
||||
|
||||
The units of the framenumber are determined by media mapping. A
|
||||
vorbis audio bitstream, for example, defines one frame to be the
|
||||
channel values from a single sampling period (eg, a 16 bit stereo
|
||||
bitstream consists of two samples of two bytes for a total of four
|
||||
bytes, thus a frame would be four bytes). A video stream defines one
|
||||
frame to be a single frame of video.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_page_pageno(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the sequential page number of the given Ogg page. The first
|
||||
page in a logical bitstream is numbered zero; following pages are
|
||||
numbered in increasing monotonic order.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_page_serialno(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the serial number of the given Ogg page. The serial number is
|
||||
used as a handle to distinguish various logical bitstreams in a
|
||||
physical Ogg bitstresm. Every logical bitstream within a
|
||||
physical bitstream must use a unique (within the scope of the physical
|
||||
bitstream) serial number, which is stamped on all bitstream pages.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_page_version(ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Returns the revision of the Ogg bitstream structure of the given page.
|
||||
Currently, the only permitted number is zero. Later revisions of the
|
||||
bitstream spec will increment this version should any changes be
|
||||
incompatable.</p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_clear(ogg_stream_state *os);
|
||||
</h3>
|
||||
|
||||
Clears and deallocates the internal storage of the given Ogg stream.
|
||||
After clearing, the stream structure is not initialized for use;
|
||||
<tt>ogg_stream_init</tt> must be called to reinitialize for use.
|
||||
Use <tt>ogg_stream_reset</tt> to reset the stream state
|
||||
to a fresh, intiialized state.<p>
|
||||
|
||||
<tt>ogg_stream_clear</tt> does not call <tt>free()</tt> on the pointer
|
||||
<tt>os</tt>, allowing use of this call on stream structures in static
|
||||
or automatic storage. <tt>ogg_stream_destroy</tt>is a complimentary
|
||||
function that frees the pointer as well.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure. This function always
|
||||
succeeds.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_destroy(ogg_stream_state *os);
|
||||
</h3>
|
||||
|
||||
Clears and deallocates the internal storage of the given Ogg stream,
|
||||
then frees the storage associated with the pointer <tt>os</tt>.<p>
|
||||
|
||||
<tt>ogg_stream_clear</tt> does not call <tt>free()</tt> on the pointer
|
||||
<tt>os</tt>, allowing use of that call on stream structures in static
|
||||
or automatic storage.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure. This function always
|
||||
succeeds.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_init(ogg_stream_state *os,int serialno);
|
||||
</h3>
|
||||
|
||||
Initialize the storage associated with <tt>os</tt> for use as an Ogg
|
||||
stream. This call is used to initialize a stream for both encode and
|
||||
decode. The given serial number is the serial number that will be
|
||||
stamped on pages of the produced bitstream (during encode), or used as
|
||||
a check that pages match (during decode).<p>
|
||||
|
||||
Returns zero on success, nonzero on failure.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_packetin(ogg_stream_state *os, ogg_packet *op);
|
||||
</h3>
|
||||
|
||||
Used during encoding to add the given raw packet to the given Ogg
|
||||
bitstream. The contents of <tt>op</tt> are copied;
|
||||
<tt>ogg_stream_packetin</tt> does not retain any pointers into
|
||||
<tt>op</tt>'s storage. The encoding proccess buffers incoming packets
|
||||
until enough packets have been assembled to form an entire page;
|
||||
<tt>ogg_stream_pageout</tt> is used to read complete pages.<p>
|
||||
|
||||
Returns zero on success, nonzero on failure.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
|
||||
</h3>
|
||||
|
||||
Used during decoding to read raw packets from the given logical
|
||||
bitstream. <tt>ogg_stream_packetout</tt> will only return complete
|
||||
packets for which checksumming indicates no corruption. The size and
|
||||
contents of the packet exactly match those given in the encoding
|
||||
process. <p>
|
||||
|
||||
Returns zero if the next packet is not ready to be read (not buffered
|
||||
or incomplete), positive if it returned a complete packet in
|
||||
<tt>op</tt> and negative if there is a gap, extra bytes or corruption
|
||||
at this position in the bitstream (essentially that the bitstream had
|
||||
to be recaptured). A negative value is not necessarily an error. It
|
||||
would be a common occurence when seeking, for example, which requires
|
||||
recapture of the bitstream at the position decoding continued.<p>
|
||||
|
||||
Iff the return value is positive, <tt>ogg_stream_packetout</tt> placed
|
||||
a packet in <tt>op</tt>. The data in <t>op</tt> points to static
|
||||
storage that is valid until the next call to
|
||||
<tt>ogg_stream_pagein</tt>, <tt>ogg_stream_clear</tt>,
|
||||
<tt>ogg_stream_reset</tt>, or <tt>ogg_stream_destroy</tt>. The
|
||||
pointers are not invalidated by more calls to
|
||||
<tt>ogg_stream_packetout</tt>.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Used during decoding to buffer the given complete, pre-verified page
|
||||
for decoding into raw Ogg packets. The given page must be framed,
|
||||
normally produced by <tt>ogg_sync_pageout</tt>, and from the logical
|
||||
bitstream associated with <tt>os</tt> (the serial numbers must match).
|
||||
The contents of the given page are copied; <tt>ogg_stream_pagein</tt>
|
||||
retains no pointers into <tt>og</tt> storage.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Used during encode to read complete pages from the stream buffer. The
|
||||
returned page is ready for sending out to the real world.<p>
|
||||
|
||||
Returns zero if there is no complete page ready for reading. Returns
|
||||
nonzero when it has placed data for a complete page into
|
||||
<tt>og</tt>. Note that the storage returned in og points into internal
|
||||
storage; the pointers in <tt>og</tt> are valid until the next call to
|
||||
<tt>ogg_stream_pageout</tt>, <tt>ogg_stream_packetin</tt>,
|
||||
<tt>ogg_stream_reset</tt>, <tt>ogg_stream_clear</tt> or
|
||||
<tt>ogg_stream_destroy</tt>.
|
||||
|
||||
<h3>
|
||||
int ogg_stream_reset(ogg_stream_state *os);
|
||||
</h3>
|
||||
|
||||
Resets the given stream's state to that of a blank, unused stream;
|
||||
this may be used during encode or decode. <p>
|
||||
|
||||
Note that if used during encode, it does not alter the stream's serial
|
||||
number. In addition, the next page produced during encoding will be
|
||||
marked as the 'initial' page of the logical bitstream.<p>
|
||||
|
||||
When used during decode, this simply clears the data buffer of any
|
||||
pending pages. Beginning and end of stream cues are read from the
|
||||
bitstream and are unaffected by reset.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure. This function always
|
||||
succeeds.<p>
|
||||
|
||||
<h3>
|
||||
char *ogg_sync_buffer(ogg_sync_state *oy, long size);
|
||||
</h3>
|
||||
|
||||
This call is used to buffer a raw bitstream for framing and
|
||||
verification. <tt>ogg_sync_buffer</tt> handles stream capture and
|
||||
recapture, checksumming, and division into Ogg pages (as required by
|
||||
<tt>ogg_stream_pagein</tt>).<p>
|
||||
|
||||
<tt>ogg_sync_buffer</tt> exposes a buffer area into which the decoder
|
||||
copies the next (up to) <tt>size</tt> bytes. We expose the buffer
|
||||
(rather than taking a buffer) in order to avoid an extra copy many
|
||||
uses; this way, for example, <tt>read()</tt> can transfer data
|
||||
directly into the stream buffer without first needing to place it in
|
||||
temporary storage.<p>
|
||||
|
||||
Returns a pointer into <tt>oy</tt>'s internal bitstream sync buffer;
|
||||
the remaining space in the sync buffer is at least <tt>size</tt>
|
||||
bytes. The decoder need not write all of <tt>size</tt> bytes;
|
||||
<tt>ogg_sync_wrote</tt> is used to inform the engine how many bytes
|
||||
were actually written. Use of <tt>ogg_sync_wrote</tt> after writing
|
||||
into the exposed buffer is mandantory.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_sync_clear(ogg_sync_state *oy);
|
||||
</h3>
|
||||
|
||||
<tt>ogg_sync_clear</tt>
|
||||
|
||||
Clears and deallocates the internal storage of the given Ogg sync
|
||||
buffer. After clearing, the sync structure is not initialized for
|
||||
use; <tt>ogg_sync_init</tt> must be called to reinitialize for use.
|
||||
Use <tt>ogg_sync_reset</tt> to reset the sync state and buffer to a
|
||||
fresh, intiialized state.<p>
|
||||
|
||||
<tt>ogg_sync_clear</tt> does not call <tt>free()</tt> on the pointer
|
||||
<tt>oy</tt>, allowing use of this call on sync structures in static
|
||||
or automatic storage. <tt>ogg_sync_destroy</tt>is a complimentary
|
||||
function that frees the pointer as well.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure. This function always
|
||||
succeeds.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_sync_destroy(ogg_sync_state *oy);
|
||||
</h3>
|
||||
|
||||
Clears and deallocates the internal storage of the given Ogg sync
|
||||
buffer, then frees the storage associated with the pointer
|
||||
<tt>oy</tt>.<p>
|
||||
|
||||
<tt>ogg_sync_clear</tt> does not call <tt>free()</tt> on the pointer
|
||||
<tt>oy</tt>, allowing use of that call on stream structures in static
|
||||
or automatic storage.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure. This function always
|
||||
succeeds.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_sync_init(ogg_sync_state *oy);
|
||||
</h3>
|
||||
|
||||
Initializes the sync buffer <tt>oy</tt> for use.<p>
|
||||
Returns zero on success and non-zero on failure. This function always
|
||||
succeeds.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og);
|
||||
</h3>
|
||||
|
||||
Reads complete, framed, verified Ogg pages from the sync buffer,
|
||||
placing the page data in <tt>og</tt>.<p>
|
||||
|
||||
Returns zero when there's no complete pages buffered for
|
||||
retrieval. Returns negative when a loss of sync or recapture occurred
|
||||
(this is not necessarily an error; recapture would be required after
|
||||
seeking, for example). Returns positive when a page is returned in
|
||||
<tt>og</tt>. Note that the data in <tt>og</tt> points into the sync
|
||||
buffer storage; the pointers are valid until the next call to
|
||||
<tt>ogg_sync_buffer</tt>, <tt>ogg_sync_clear</tt>,
|
||||
<tt>ogg_sync_destroy</tt> or <tt>ogg_sync_reset</tt>.
|
||||
|
||||
|
||||
<h3>
|
||||
int ogg_sync_reset(ogg_sync_state *oy);
|
||||
</h3>
|
||||
|
||||
<tt>ogg_sync_reset</tt> resets the sync state in <tt>oy</tt> to a
|
||||
clean, empty state. This is useful, for example, when seeking to a
|
||||
new location in a bitstream.<p>
|
||||
|
||||
Returns zero on success, nonzero on failure.<p>
|
||||
|
||||
<h3>
|
||||
int ogg_sync_wrote(ogg_sync_state *oy, long bytes);
|
||||
</h3>
|
||||
|
||||
Used to inform the sync state as to how many bytes were actually
|
||||
written into the exposed sync buffer. It must be equal to or less
|
||||
than the size of the buffer requested.<p>
|
||||
|
||||
Returns zero on success and non-zero on failure; failure occurs only
|
||||
when the number of bytes written were larger than the buffer.<p>
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org"></a> effort to
|
||||
protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
@@ -0,0 +1,371 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
||||
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg Vorbis stereo-specific channel coupling discussion
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 16, 2002</em><br>
|
||||
|
||||
<h2>Abstract</h2> The Vorbis audio CODEC provides a channel coupling
|
||||
mechanisms designed to reduce effective bitrate by both eliminating
|
||||
interchannel redundancy and eliminating stereo image information
|
||||
labeled inaudible or undesirable according to spatial psychoacoustic
|
||||
models. This document describes both the mechanical coupling
|
||||
mechanisms available within the Vorbis specification, as well as the
|
||||
specific stereo coupling models used by the reference
|
||||
<tt>libvorbis</tt> codec provided by xiph.org.
|
||||
|
||||
<h2>Mechanisms</h2>
|
||||
|
||||
In encoder release beta 4 and earlier, Vorbis supported multiple
|
||||
channel encoding, but the channels were encoded entirely separately
|
||||
with no cross-analysis or redundancy elimination between channels.
|
||||
This multichannel strategy is very similar to the mp3's <em>dual
|
||||
stereo</em> mode and Vorbis uses the same name for its analogous
|
||||
uncoupled multichannel modes.<p>
|
||||
|
||||
However, the Vorbis spec provides for, and Vorbis release 1.0 rc1 and
|
||||
later implement a coupled channel strategy. Vorbis has two specific
|
||||
mechanisms that may be used alone or in conjunction to implement
|
||||
channel coupling. The first is <em>channel interleaving</em> via
|
||||
residue backend type 2, and the second is <em>square polar
|
||||
mapping</em>. These two general mechanisms are particularly well
|
||||
suited to coupling due to the structure of Vorbis encoding, as we'll
|
||||
explore below, and using both we can implement both totally
|
||||
<em>lossless stereo image coupling</em> [bit-for-bit decode-identical
|
||||
to uncoupled modes], as well as various lossy models that seek to
|
||||
eliminate inaudible or unimportant aspects of the stereo image in
|
||||
order to enhance bitrate. The exact coupling implementation is
|
||||
generalized to allow the encoder a great deal of flexibility in
|
||||
implementation of a stereo or surround model without requiring any
|
||||
significant complexity increase over the combinatorially simpler
|
||||
mid/side joint stereo of mp3 and other current audio codecs.<p>
|
||||
|
||||
A particular Vorbis bitstream may apply channel coupling directly to
|
||||
more than a pair of channels; polar mapping is hierarchical such that
|
||||
polar coupling may be extrapolated to an arbitrary number of channels
|
||||
and is not restricted to only stereo, quadraphonics, ambisonics or 5.1
|
||||
surround. However, the scope of this document restricts itself to the
|
||||
stereo coupling case.<p>
|
||||
|
||||
<h3>Square Polar Mapping</h3>
|
||||
|
||||
<h4>maximal correlation</h4>
|
||||
|
||||
Recall that the basic structure of a a Vorbis I stream first generates
|
||||
from input audio a spectral 'floor' function that serves as an
|
||||
MDCT-domain whitening filter. This floor is meant to represent the
|
||||
rough envelope of the frequency spectrum, using whatever metric the
|
||||
encoder cares to define. This floor is subtracted from the log
|
||||
frequency spectrum, effectively normalizing the spectrum by frequency.
|
||||
Each input channel is associated with a unique floor function.<p>
|
||||
|
||||
The basic idea behind any stereo coupling is that the left and right
|
||||
channels usually correlate. This correlation is even stronger if one
|
||||
first accounts for energy differences in any given frequency band
|
||||
across left and right; think for example of individual instruments
|
||||
mixed into different portions of the stereo image, or a stereo
|
||||
recording with a dominant feature not perfectly in the center. The
|
||||
floor functions, each specific to a channel, provide the perfect means
|
||||
of normalizing left and right energies across the spectrum to maximize
|
||||
correlation before coupling. This feature of the Vorbis format is not
|
||||
a convenient accident.<p>
|
||||
|
||||
Because we strive to maximally correlate the left and right channels
|
||||
and generally succeed in doing so, left and right residue is typically
|
||||
nearly identical. We could use channel interleaving (discussed below)
|
||||
alone to efficiently remove the redundancy between the left and right
|
||||
channels as a side effect of entropy encoding, but a polar
|
||||
representation gives benefits when left/right correlation is
|
||||
strong. <p>
|
||||
|
||||
<h4>point and diffuse imaging</h4>
|
||||
|
||||
The first advantage of a polar representation is that it effectively
|
||||
separates the spatial audio information into a 'point image'
|
||||
(magnitude) at a given frequency and located somewhere in the sound
|
||||
field, and a 'diffuse image' (angle) that fills a large amount of
|
||||
space simultaneously. Even if we preserve only the magnitude (point)
|
||||
data, a detailed and carefully chosen floor function in each channel
|
||||
provides us with a free, fine-grained, frequency relative intensity
|
||||
stereo*. Angle information represents diffuse sound fields, such as
|
||||
reverberation that fills the entire space simultaneously.<p>
|
||||
|
||||
*<em>Because the Vorbis model supports a number of different possible
|
||||
stereo models and these models may be mixed, we do not use the term
|
||||
'intensity stereo' talking about Vorbis; instead we use the terms
|
||||
'point stereo', 'phase stereo' and subcategories of each.</em><p>
|
||||
|
||||
The majority of a stereo image is representable by polar magnitude
|
||||
alone, as strong sounds tend to be produced at near-point sources;
|
||||
even non-diffuse, fast, sharp echoes track very accurately using
|
||||
magnitude representation almost alone (for those experimenting with
|
||||
Vorbis tuning, this strategy works much better with the precise,
|
||||
piecewise control of floor 1; the continuous approximation of floor 0
|
||||
results in unstable imaging). Reverberation and diffuse sounds tend
|
||||
to contain less energy and be psychoacoustically dominated by the
|
||||
point sources embedded in them. Thus, we again tend to concentrate
|
||||
more represented energy into a predictably smaller number of numbers.
|
||||
Separating representation of point and diffuse imaging also allows us
|
||||
to model and manipulate point and diffuse qualities separately.<p>
|
||||
|
||||
<h4>controlling bit leakage and symbol crosstalk</h4> Because polar
|
||||
representation concentrates represented energy into fewer large
|
||||
values, we reduce bit 'leakage' during cascading (multistage VQ
|
||||
encoding) as a secondary benefit. A single large, monolithic VQ
|
||||
codebook is more efficient than a cascaded book due to entropy
|
||||
'crosstalk' among symbols between different stages of a multistage cascade.
|
||||
Polar representation is a way of further concentrating entropy into
|
||||
predictable locations so that codebook design can take steps to
|
||||
improve multistage codebook efficiency. It also allows us to cascade
|
||||
various elements of the stereo image independently.<p>
|
||||
|
||||
<h4>eliminating trigonometry and rounding</h4>
|
||||
|
||||
Rounding and computational complexity are potential problems with a
|
||||
polar representation. As our encoding process involves quantization,
|
||||
mixing a polar representation and quantization makes it potentially
|
||||
impossible, depending on implementation, to construct a coupled stereo
|
||||
mechanism that results in bit-identical decompressed output compared
|
||||
to an uncoupled encoding should the encoder desire it.<p>
|
||||
|
||||
Vorbis uses a mapping that preserves the most useful qualities of
|
||||
polar representation, relies only on addition/subtraction (during
|
||||
decode; high quality encoding still requires some trig), and makes it
|
||||
trivial before or after quantization to represent an angle/magnitude
|
||||
through a one-to-one mapping from possible left/right value
|
||||
permutations. We do this by basing our polar representation on the
|
||||
unit square rather than the unit-circle.<p>
|
||||
|
||||
Given a magnitude and angle, we recover left and right using the
|
||||
following function (note that A/B may be left/right or right/left
|
||||
depending on the coupling definition used by the encoder):<p>
|
||||
|
||||
<pre>
|
||||
if(magnitude>0)
|
||||
if(angle>0){
|
||||
A=magnitude;
|
||||
B=magnitude-angle;
|
||||
}else{
|
||||
B=magnitude;
|
||||
A=magnitude+angle;
|
||||
}
|
||||
else
|
||||
if(angle>0){
|
||||
A=magnitude;
|
||||
B=magnitude+angle;
|
||||
}else{
|
||||
B=magnitude;
|
||||
A=magnitude-angle;
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
The function is antisymmetric for positive and negative magnitudes in
|
||||
order to eliminate a redundant value when quantizing. For example, if
|
||||
we're quantizing to integer values, we can visualize a magnitude of 5
|
||||
and an angle of -2 as follows:<p>
|
||||
|
||||
<img src="squarepolar.png">
|
||||
|
||||
<p>
|
||||
This representation loses or replicates no values; if the range of A
|
||||
and B are integral -5 through 5, the number of possible Cartesian
|
||||
permutations is 121. Represented in square polar notation, the
|
||||
possible values are:
|
||||
|
||||
<pre>
|
||||
0, 0
|
||||
|
||||
-1,-2 -1,-1 -1, 0 -1, 1
|
||||
|
||||
1,-2 1,-1 1, 0 1, 1
|
||||
|
||||
-2,-4 -2,-3 -2,-2 -2,-1 -2, 0 -2, 1 -2, 2 -2, 3
|
||||
|
||||
2,-4 2,-3 ... following the pattern ...
|
||||
|
||||
... 5, 1 5, 2 5, 3 5, 4 5, 5 5, 6 5, 7 5, 8 5, 9
|
||||
|
||||
</pre>
|
||||
|
||||
...for a grand total of 121 possible values, the same number as in
|
||||
Cartesian representation (note that, for example, <tt>5,-10</tt> is
|
||||
the same as <tt>-5,10</tt>, so there's no reason to represent
|
||||
both. 2,10 cannot happen, and there's no reason to account for it.)
|
||||
It's also obvious that this mapping is exactly reversible.<p>
|
||||
|
||||
<h3>Channel interleaving</h3>
|
||||
|
||||
We can remap and A/B vector using polar mapping into a magnitude/angle
|
||||
vector, and it's clear that, in general, this concentrates energy in
|
||||
the magnitude vector and reduces the amount of information to encode
|
||||
in the angle vector. Encoding these vectors independently with
|
||||
residue backend #0 or residue backend #1 will result in bitrate
|
||||
savings. However, there are still implicit correlations between the
|
||||
magnitude and angle vectors. The most obvious is that the amplitude
|
||||
of the angle is bounded by its corresponding magnitude value.<p>
|
||||
|
||||
Entropy coding the results, then, further benefits from the entropy
|
||||
model being able to compress magnitude and angle simultaneously. For
|
||||
this reason, Vorbis implements residue backend #2 which pre-interleaves
|
||||
a number of input vectors (in the stereo case, two, A and B) into a
|
||||
single output vector (with the elements in the order of
|
||||
A_0, B_0, A_1, B_1, A_2 ... A_n-1, B_n-1) before entropy encoding. Thus
|
||||
each vector to be coded by the vector quantization backend consists of
|
||||
matching magnitude and angle values.<p>
|
||||
|
||||
The astute reader, at this point, will notice that in the theoretical
|
||||
case in which we can use monolithic codebooks of arbitrarily large
|
||||
size, we can directly interleave and encode left and right without
|
||||
polar mapping; in fact, the polar mapping does not appear to lend any
|
||||
benefit whatsoever to the efficiency of the entropy coding. In fact,
|
||||
it is perfectly possible and reasonable to build a Vorbis encoder that
|
||||
dispenses with polar mapping entirely and merely interleaves the
|
||||
channel. Libvorbis based encoders may configure such an encoding and
|
||||
it will work as intended.<p>
|
||||
|
||||
However, when we leave the ideal/theoretical domain, we notice that
|
||||
polar mapping does give additional practical benefits, as discussed in
|
||||
the above section on polar mapping and summarized again here:<p>
|
||||
<ul>
|
||||
<li>Polar mapping aids in controlling entropy 'leakage' between stages
|
||||
of a cascaded codebook. <li>Polar mapping separates the stereo image
|
||||
into point and diffuse components which may be analyzed and handled
|
||||
differently.
|
||||
</ul>
|
||||
|
||||
<h2>Stereo Models</h2>
|
||||
|
||||
<h3>Dual Stereo</h3>
|
||||
|
||||
Dual stereo refers to stereo encoding where the channels are entirely
|
||||
separate; they are analyzed and encoded as entirely distinct entities.
|
||||
This terminology is familiar from mp3.<p>
|
||||
|
||||
<h3>Lossless Stereo</h3>
|
||||
|
||||
Using polar mapping and/or channel interleaving, it's possible to
|
||||
couple Vorbis channels losslessly, that is, construct a stereo
|
||||
coupling encoding that both saves space but also decodes
|
||||
bit-identically to dual stereo. OggEnc 1.0 and later uses this
|
||||
mode in all high-bitrate encoding.<p>
|
||||
|
||||
Overall, this stereo mode is overkill; however, it offers a safe
|
||||
alternative to users concerned about the slightest possible
|
||||
degradation to the stereo image or archival quality audio.<p>
|
||||
|
||||
<h3>Phase Stereo</h3>
|
||||
|
||||
Phase stereo is the least aggressive means of gracefully dropping
|
||||
resolution from the stereo image; it affects only diffuse imaging.<p>
|
||||
|
||||
It's often quoted that the human ear is deaf to signal phase above
|
||||
about 4kHz; this is nearly true and a passable rule of thumb, but it
|
||||
can be demonstrated that even an average user can tell the difference
|
||||
between high frequency in-phase and out-of-phase noise. Obviously
|
||||
then, the statement is not entirely true. However, it's also the case
|
||||
that one must resort to nearly such an extreme demonstration before
|
||||
finding the counterexample.<p>
|
||||
|
||||
'Phase stereo' is simply a more aggressive quantization of the polar
|
||||
angle vector; above 4kHz it's generally quite safe to quantize noise
|
||||
and noisy elements to only a handful of allowed phases, or to thin the
|
||||
phase with respect to the magnitude. The phases of high amplitude
|
||||
pure tones may or may not be preserved more carefully (they are
|
||||
relatively rare and L/R tend to be in phase, so there is generally
|
||||
little reason not to spend a few more bits on them) <p>
|
||||
|
||||
<h4>example: eight phase stereo</h4>
|
||||
|
||||
Vorbis may implement phase stereo coupling by preserving the entirety
|
||||
of the magnitude vector (essential to fine amplitude and energy
|
||||
resolution overall) and quantizing the angle vector to one of only
|
||||
four possible values. Given that the magnitude vector may be positive
|
||||
or negative, this results in left and right phase having eight
|
||||
possible permutation, thus 'eight phase stereo':<p>
|
||||
|
||||
<img src="eightphase.png"><p>
|
||||
|
||||
Left and right may be in phase (positive or negative), the most common
|
||||
case by far, or out of phase by 90 or 180 degrees.<p>
|
||||
|
||||
<h4>example: four phase stereo</h4>
|
||||
|
||||
Similarly, four phase stereo takes the quantization one step further;
|
||||
it allows only in-phase and 180 degree out-out-phase signals:<p>
|
||||
|
||||
<img src="fourphase.png"><p>
|
||||
|
||||
<h3>example: point stereo</h3>
|
||||
|
||||
Point stereo eliminates the possibility of out-of-phase signal
|
||||
entirely. Any diffuse quality to a sound source tends to collapse
|
||||
inward to a point somewhere within the stereo image. A practical
|
||||
example would be balanced reverberations within a large, live space;
|
||||
normally the sound is diffuse and soft, giving a sonic impression of
|
||||
volume. In point-stereo, the reverberations would still exist, but
|
||||
sound fairly firmly centered within the image (assuming the
|
||||
reverberation was centered overall; if the reverberation is stronger
|
||||
to the left, then the point of localization in point stereo would be
|
||||
to the left). This effect is most noticeable at low and mid
|
||||
frequencies and using headphones (which grant perfect stereo
|
||||
separation). Point stereo is is a graceful but generally easy to
|
||||
detect degradation to the sound quality and is thus used in frequency
|
||||
ranges where it is least noticeable.<p>
|
||||
|
||||
<h3>Mixed Stereo</h3>
|
||||
|
||||
Mixed stereo is the simultaneous use of more than one of the above
|
||||
stereo encoding models, generally using more aggressive modes in
|
||||
higher frequencies, lower amplitudes or 'nearly' in-phase sound.<p>
|
||||
|
||||
It is also the case that near-DC frequencies should be encoded using
|
||||
lossless coupling to avoid frame blocking artifacts.<p>
|
||||
|
||||
<h3>Vorbis Stereo Modes</h3>
|
||||
|
||||
Vorbis, as of 1.0, uses lossless stereo and a number of mixed modes
|
||||
constructed out of lossless and point stereo. Phase stereo was used
|
||||
in the rc2 encoder, but is not currently used for simplicity's sake. It
|
||||
will likely be re-added to the stereo model in the future.
|
||||
|
||||
<p>
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
</body>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 2.3 KiB |
@@ -0,0 +1,231 @@
|
||||
<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
|
||||
<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
|
||||
<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p>
|
||||
|
||||
|
||||
<h1><font color=#000070>
|
||||
Ogg Vorbis I format specification: comment field and header specification
|
||||
</font></h1>
|
||||
|
||||
<em>Last update to this document: July 16, 2002</em><p>
|
||||
|
||||
<h1>Overview</h1>
|
||||
|
||||
<p>The Vorbis text comment header is the second (of three) header
|
||||
packets that begin a Vorbis bitstream. It is meant for short, text
|
||||
comments, not arbitrary metadata; arbitrary metadata belongs in a
|
||||
separate logical bitstream (usually an XML stream type) that provides
|
||||
greater structure and machine parseability.
|
||||
|
||||
<p>The comment field is meant to be used much like someone jotting a
|
||||
quick note on the bottom of a CDR. It should be a little information to
|
||||
remember the disc by and explain it to others; a short, to-the-point
|
||||
text note that need not only be a couple words, but isn't going to be
|
||||
more than a short paragraph. The essentials, in other words, whatever
|
||||
they turn out to be, eg:
|
||||
|
||||
<blockquote>
|
||||
"Honest Bob and the Factory-to-Dealer-Incentives, _I'm Still Around_,
|
||||
opening for Moxy Fruvous, 1997"
|
||||
</blockquote>
|
||||
|
||||
<h1>Comment encoding</h1>
|
||||
|
||||
|
||||
<h2>Structure</h2>
|
||||
|
||||
The comment header logically is a list of eight-bit-clean vectors; the
|
||||
number of vectors is bounded to 2^32-1 and the length of each vector
|
||||
is limited to 2^32-1 bytes. The vector length is encoded; the vector
|
||||
contents themselves are not null terminated. In addition to the vector
|
||||
list, there is a single vector for vendor name (also 8 bit clean,
|
||||
length encoded in 32 bits). Libvorbis currently sets the vendor string
|
||||
to "Xiph.Org libVorbis I 20020717".<p>
|
||||
|
||||
The comment header is decoded as follows:<p>
|
||||
|
||||
<pre>
|
||||
1) [vendor_length] = read an unsigned integer of 32 bits
|
||||
2) [vendor_string] = read a UTF-8 vector as [vendor_length] octets
|
||||
3) [user_comment_list_length] = read an unsigned integer of 32 bits
|
||||
4) iterate [user_comment_list_length] times {
|
||||
|
||||
5) [length] = read an unsigned integer of 32 bits
|
||||
6) this iteration's user comment = read a UTF-8 vector as [length] octets
|
||||
|
||||
}
|
||||
|
||||
7) [framing_bit] = read a single bit as boolean
|
||||
8) if ( [framing_bit] unset or end of packet ) then ERROR
|
||||
9) done.
|
||||
</pre>
|
||||
|
||||
|
||||
<h2>Content vector format</h2>
|
||||
|
||||
The comment vectors are structured similarly to a UNIX environment variable.
|
||||
That is, comment fields consist of a field name and a field value and
|
||||
look like:
|
||||
|
||||
<pre>
|
||||
comment[0]="ARTIST=me";
|
||||
comment[1]="TITLE=the sound of Vorbis";
|
||||
</pre>
|
||||
|
||||
<ul>
|
||||
<li>A case-insensitive field name that may consist of ASCII 0x20 through
|
||||
0x7D, 0x3D ('=') excluded. ASCII 0x41 through 0x5A inclusive (A-Z) is
|
||||
to be considered equivalent to ASCII 0x61 through 0x7A inclusive
|
||||
(a-z).
|
||||
|
||||
<li>The field name is immediately followed by ASCII 0x3D ('='); this
|
||||
equals sign is used to terminate the field name.
|
||||
|
||||
<li>0x3D is followed by 8 bit clean UTF-8 encoded field contents
|
||||
to the end of the field.
|
||||
</ul>
|
||||
|
||||
<h3>Field names</h3>
|
||||
|
||||
Below is a proposed, minimal list of standard filed names with a
|
||||
description of intended use. No single or group of field names is
|
||||
mandatory; a comment header may contain one, all or none of the names
|
||||
in this list.<p>
|
||||
|
||||
<dl>
|
||||
<dt>TITLE<dd>Track/Work name
|
||||
|
||||
<dt>VERSION<dd>The version field may be used to differentiate multiple
|
||||
versions of the same track title in a single collection. (e.g. remix info)
|
||||
|
||||
<dt>ALBUM<dd>The collection name to which this track belongs
|
||||
|
||||
<dt>TRACKNUMBER<dd>The track number of this piece if part of a specific larger collection or album
|
||||
|
||||
<dt>ARTIST<dd>The artist generally considered responsible for the work. In popular music this is usually the performing band or singer. For classical music it would be the composer. For an audio book it would be the author of the original text.
|
||||
|
||||
<dt>PERFORMER<dd>The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is omitted.
|
||||
|
||||
<dt>COPYRIGHT<dd>Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
|
||||
|
||||
<dt>LICENSE<dd>License information, eg, 'All Rights Reserved', 'Any
|
||||
Use Permitted', a URL to a license such as a Creative Commons license
|
||||
("www.creativecommons.org/blahblah/license.html") or the EFF Open
|
||||
Audio License ('distributed under the terms of the Open Audio
|
||||
License. see http://www.eff.org/IP/Open_licenses/eff_oal.html for
|
||||
details'), etc.
|
||||
|
||||
<dt>ORGANIZATION<dd>Name of the organization producing the track (i.e.
|
||||
the 'record label')
|
||||
|
||||
<dt>DESCRIPTION<dd>A short text description of the contents
|
||||
|
||||
<dt>GENRE<dd>A short text indication of music genre
|
||||
|
||||
<dt>DATE<dd>Date the track was recorded
|
||||
|
||||
<dt>LOCATION<dd>Location where track was recorded
|
||||
|
||||
<dt>CONTACT<dd>Contact information for the creators or distributors of the track. This could be a URL, an email address, the physical address of the producing label.
|
||||
|
||||
<dt>ISRC<dd>ISRC number for the track; see <a href="http://www.ifpi.org/site-content/online/isrc_intro.html">the ISRC intro page</a> for more information on ISRC numbers.
|
||||
|
||||
</dl>
|
||||
|
||||
<h3>Implications</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Field names should not be 'internationalized'; this is a
|
||||
concession to simplicity not an attempt to exclude the majority of
|
||||
the world that doesn't speak English. Field *contents*, however,
|
||||
are represented in UTF-8 to allow easy representation of any language.
|
||||
<li>
|
||||
We have the length of the entirety of the field and restrictions on
|
||||
the field name so that the field name is bounded in a known way. Thus
|
||||
we also have the length of the field contents.
|
||||
<li>
|
||||
Individual 'vendors' may use non-standard field names within
|
||||
reason. The proper use of comment fields should be clear through
|
||||
context at this point. Abuse will be discouraged.
|
||||
<li>
|
||||
There is no vendor-specific prefix to 'nonstandard' field names.
|
||||
Vendors should make some effort to avoid arbitrarily polluting the
|
||||
common namespace. We will generally collect the more useful tags
|
||||
here to help with standardization.
|
||||
<li>
|
||||
Field names are not required to be unique (occur once) within a
|
||||
comment header. As an example, assume a track was recorded by three
|
||||
well know artists; the following is permissible, and encouraged:
|
||||
<pre>
|
||||
ARTIST=Dizzy Gillespie
|
||||
ARTIST=Sonny Rollins
|
||||
ARTIST=Sonny Stitt
|
||||
</pre>
|
||||
|
||||
</ul>
|
||||
|
||||
<h2>Encoding</h2>
|
||||
|
||||
The comment header comprises the entirety of the second bitstream
|
||||
header packet. Unlike the first bitstream header packet, it is not
|
||||
generally the only packet on the second page and may not be restricted
|
||||
to within the second bitstream page. The length of the comment header
|
||||
packet is [practically] unbounded. The comment header packet is not
|
||||
optional; it must be present in the bitstream even if it is
|
||||
effectively empty.<p>
|
||||
|
||||
The comment header is encoded as follows (as per Ogg's standard
|
||||
bitstream mapping which renders least-significant-bit of the word to be
|
||||
coded into the least significant available bit of the current
|
||||
bitstream octet first):
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
Vendor string length (32 bit unsigned quantity specifying number of octets)
|
||||
|
||||
<li>
|
||||
Vendor string ([vendor string length] octets coded from beginning of string to end of string, not null terminated)
|
||||
|
||||
<li>Number of comment fields (32 bit unsigned quantity specifying number of fields)
|
||||
|
||||
<li>Comment field 0 length (if [Number of comment fields]>0; 32 bit unsigned quantity specifying number of octets)
|
||||
|
||||
<li>
|
||||
Comment field 0 ([Comment field 0 length] octets coded from beginning of string to end of string, not null terminated)
|
||||
|
||||
<li>Comment field 1 length (if [Number of comment fields]>1...)...
|
||||
</ol>
|
||||
|
||||
This is actually somewhat easier to describe in code; implementation of the above can be found in vorbis/lib/info.c:_vorbis_pack_comment(),_vorbis_unpack_comment()
|
||||
|
||||
<hr>
|
||||
<a href="http://www.xiph.org/">
|
||||
<img src="white-xifish.png" align=left border=0>
|
||||
</a>
|
||||
<font size=-2 color=#505050>
|
||||
|
||||
Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
|
||||
to protect essential tenets of Internet multimedia from corporate
|
||||
hostage-taking; Open Source is the net's greatest tool to keep
|
||||
everyone honest. See <a href="http://www.xiph.org/about.html">About
|
||||
the Xiph.org Foundation</a> for details.
|
||||
<p>
|
||||
|
||||
Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
|
||||
distribute the Ogg and Vorbis specification, whether in a private,
|
||||
public or corporate capacity. However, the Xiph.org Foundation and
|
||||
the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
|
||||
specification and certify specification compliance.<p>
|
||||
|
||||
Xiph.org's Vorbis software CODEC implementation is distributed under a
|
||||
BSD-like license. This does not restrict third parties from
|
||||
distributing independent implementations of Vorbis software under
|
||||
other licenses.<p>
|
||||
|
||||
Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
|
||||
of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
|
||||
pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
|
||||
reserved.<p>
|
||||
|
||||
</body>
|
||||
|
||||
@@ -0,0 +1,139 @@
|
||||
Topic:
|
||||
|
||||
Sample granularity editing of a Vorbis file; inferred arbitrary sample
|
||||
length starting offsets / PCM stream lengths
|
||||
|
||||
Overview:
|
||||
|
||||
Vorbis, like mp3, is a frame-based* audio compression where audio is
|
||||
broken up into discrete short time segments. These segments are
|
||||
'atomic' that is, one must recover the entire short time segment from
|
||||
the frame packet; there's no way to recover only a part of the PCM time
|
||||
segment from part of the coded packet without expanding the entire
|
||||
packet and then discarding a portion of the resulting PCM audio.
|
||||
|
||||
* In mp3, the data segment representing a given time period is called
|
||||
a 'frame'; the roughly equivalent Vorbis construct is a 'packet'.
|
||||
|
||||
Thus, when we edit a Vorbis stream, the finest physical editing
|
||||
granularity is on these packet boundaries (the mp3 case is
|
||||
actually somewhat more complex and mp3 editing is more complicated
|
||||
than just snipping on a frame boundary because time data can be spread
|
||||
backward or forward over frames. In Vorbis, packets are all
|
||||
stand-alone). Thus, at the physical packet level, Vorbis is still
|
||||
limited to streams that contain an integral number of packets.
|
||||
|
||||
However, Vorbis streams may still exactly represent and be edited to a
|
||||
PCM stream of arbitrary length and starting offset without padding the
|
||||
beginning or end of the decoded stream or requiring that the desired
|
||||
edit points be packet aligned. Vorbis makes use of Ogg stream
|
||||
framing, and this framing provides time-stamping data, called a
|
||||
'granule position'; our starting offset and finished stream length may
|
||||
be inferred from correct usage of the granule position data.
|
||||
|
||||
Time stamping mechanism:
|
||||
|
||||
Vorbis packets are bundled into into Ogg pages (note that pages do not
|
||||
necessarily contain integral numbers of packets, but that isn't
|
||||
inportant in this discussion. More about Ogg framing can be found in
|
||||
ogg/doc/framing.html). Each page that contains a packet boundary is
|
||||
stamped with the absolute sample-granularity offset of the data, that
|
||||
is, 'complete samples-to-date' up to the last completed packet of that
|
||||
page. (The same mechanism is used for eg, video, where the number
|
||||
represents complete 2-D frames, and so on).
|
||||
|
||||
(It's possible but rare for a packet to span more than two pages such
|
||||
that page[s] in the middle have no packet boundary; these packets have
|
||||
a granule position of '-1'.)
|
||||
|
||||
This granule position mechaism in Ogg is used by Vorbis to indicate when the
|
||||
PCM data intended to be represented in a Vorbis segment begins a
|
||||
number of samples into the data represented by the first packet[s]
|
||||
and/or ends before the physical PCM data represented in the last
|
||||
packet[s].
|
||||
|
||||
File length a non-integral number of frames:
|
||||
|
||||
A file to be encoded in Vorbis will probably not encode into an
|
||||
integral number of packets; such a file is encoded with the last
|
||||
packet containing 'extra'* samples. These samples are not padding; they
|
||||
will be discarded in decode.
|
||||
|
||||
*(For best results, the encoder should use extra samples that preserve
|
||||
the character of the last frame. Simply setting them to zero will
|
||||
introduce a 'cliff' that's hard to encode, resulting in spread-frame
|
||||
noise. Libvorbis extrapolates the last frame past the end of data to
|
||||
produce the extra samples. Even simply duplicating the last value is
|
||||
better than clamping the signal to zero).
|
||||
|
||||
The encoder indicates to the decoder that the file is actually shorter
|
||||
than all of the samples ('original' + 'extra') by setting the granule
|
||||
position in the last page to a short value, that is, the last
|
||||
timestamp is the original length of the file discarding extra samples.
|
||||
The decoder will see that the number of samples it has decoded in the
|
||||
last page is too many; it is 'original' + 'extra', where the
|
||||
granulepos says that through the last packet we only have 'original'
|
||||
number of samples. The decoder then ignores the 'extra' samples.
|
||||
This behavior is to occur only when the end-of-stream bit is set in
|
||||
the page (indicating last page of the logical stream).
|
||||
|
||||
Note that it not legal for the granule position of the last page to
|
||||
indicate that there are more samples in the file than actually exist,
|
||||
however, implementations should handle such an illegal file gracefully
|
||||
in the interests of robust programming.
|
||||
|
||||
Beginning point not on integral packet boundary:
|
||||
|
||||
It is possible that we will the PCM data represented by a Vorbis
|
||||
stream to begin at a position later than where the decoded PCM data
|
||||
really begins after an integral packet boundary, a situation analagous
|
||||
to the above description where the PCM data does not end at an
|
||||
integral packet boundary. The easiest example is taking a clip out of
|
||||
a larger Vorbis stream, and choosing a beginning point of the clip
|
||||
that is not on a packet boundary; we need to ignore a few samples to
|
||||
get the desired beginning point.
|
||||
|
||||
The process of marking the desired beginning point is similar to
|
||||
marking an arbitrary ending point. If the encoder wishes sample zero
|
||||
to be some location past the actual beginning of data, it associates a
|
||||
'short' granule position value with the completion of the second*
|
||||
audio packet. The granule position is associated with the second
|
||||
packet simply by making sure the second packet completes its page.
|
||||
|
||||
*(We associate the short value with the second packet for two reasons.
|
||||
a) The first packet only primes the overlap/add buffer. No data is
|
||||
returned before decoding the second packet; this places the decision
|
||||
information at the point of decision. b) Placing the short value on
|
||||
the first packet would make the value negative (as the first packet
|
||||
normally represents position zero); a negative value would break the
|
||||
requirement that granule positions increase; the headers have
|
||||
position values of zero)
|
||||
|
||||
The decoder sees that on the first page that will return
|
||||
data from the overlap/add queue, we have more samples than the granule
|
||||
position accounts for, and discards the 'surplus' from the beginning
|
||||
of the queue.
|
||||
|
||||
Note that short granule values (indicating less than the actually
|
||||
returned about of data) are not legal in the Vorbis spec outside of
|
||||
indicating beginning and ending sample positions. However, decoders
|
||||
should, at minimum, tolerate inadvertant short values elsewhere in the
|
||||
stream (just as they should tolerate out-of-order/non-increasing
|
||||
granulepos values, although this too is illegal).
|
||||
|
||||
Beginning point at arbitrary positive timestamp (no 'zero' sample):
|
||||
|
||||
It's also possible that the granule position of the first page of an
|
||||
audio stream is a 'long value', that is, a value larger than the
|
||||
amount of PCM audio decoded. This implies only that we are starting
|
||||
playback at some point into the logical stream, a potentially common
|
||||
occurence in streaming applications where the decoder may be
|
||||
connecting into a live stream. The decoder should not treat the long
|
||||
value specially.
|
||||
|
||||
A long value elsewhere in the stream would normally occur only when a
|
||||
page is lost or out of sequence, as indicated by the page's sequence
|
||||
number. A long value under any other situation is not legal, however
|
||||
a decoder should tolerate both possibilities.
|
||||
|
||||
|
||||
Loaded 100 of 20588 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user