1 files changed, 183 insertions, 0 deletions
diff --git a/vorbis/doc/vorbisfile/ov_open.html b/vorbis/doc/vorbisfile/ov_open.html
new file mode 100644
index 0000000..d0311ce
--- /dev/null
+++ b/vorbis/doc/vorbisfile/ov_open.html
@@ -0,0 +1,183 @@
+<html>
+
+<head>
+<title>Vorbisfile - function - ov_open</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>vorbisfile version 1.3.2 - 20101101</p></td>
+</tr>
+</table>
+
+<h1>ov_open</h1>
+
+<p><i>declared in "vorbis/vorbisfile.h";</i></p>
+
+<p>ov_open is one of three initialization functions used to initialize
+an OggVorbis_File structure and prepare a bitstream for playback.
+
+<p><em><b> WARNING for Windows developers: </b> Do not use ov_open() in
+Windows applications; Windows linking places restrictions on
+passing <tt>FILE *</tt> handles successfully, and ov_open() runs
+afoul of these restrictions <a href="#winfoot">[a]</a>.  See the <a
+href="ov_open_callbacks.html">ov_open_callbacks() page </a> for
+details on using <a
+href="ov_open_callbacks.html">ov_open_callbacks()</a> instead. </em>
+
+<p>The first argument must be a file pointer to an already opened file
+or pipe (it need not be seekable--though this obviously restricts what
+can be done with the bitstream). <tt>vf</tt> should be a pointer to the
+OggVorbis_File structure -- this is used for ALL the externally visible libvorbisfile
+functions. Once this has been called, the same <a href="OggVorbis_File.html">OggVorbis_File</a>
+struct should be passed to all the libvorbisfile functions.<p>
+
+The <tt>vf</tt> structure initialized using ov_fopen() must eventually
+be cleaned using <a href="ov_clear.html">ov_clear()</a>.  Once a
+<tt>FILE *</tt> handle is passed to ov_open() successfully, the
+application MUST NOT <tt>fclose()</tt> or in any other way manipulate
+that file handle.  Vorbisfile will close the file in <a
+href="ov_clear.html">ov_clear()</a>.  If the application must be able
+to close the <tt>FILE *</tt> handle itself, see <a
+href="ov_open_callbacks.html">ov_open_callbacks()</a> with the use of
+<tt>OV_CALLBACKS_NOCLOSE</tt>.
+
+<p>It is often useful to call <tt>ov_open()</tt> simply to determine
+whether a given file is a Vorbis bitstream. If the <tt>ov_open()</tt>
+call fails, then the file is not recognizable as Vorbis.  If the call
+succeeds but the initialized <tt>vf</tt> structure will not be used,
+the application is responsible for calling <a
+href="ov_clear.html">ov_clear()</a> to clear the decoder's buffers and
+close the file.<p>
+
+If [and only if] an <tt>ov_open()</tt> call fails, the application
+must explicitly <tt>fclose()</tt> the <tt>FILE *</tt> pointer itself.
+
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ov_open(FILE *f,<a href="OggVorbis_File.html">OggVorbis_File</a> *vf,char *initial,long ibytes);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>f</i></dt>
+<dd>File pointer to an already opened file
+or pipe (it need not be seekable--though this obviously restricts what
+can be done with the bitstream).</dd>
+<dt><i>vf</i></dt>
+<dd>A pointer to the OggVorbis_File structure--this is used for ALL the externally visible libvorbisfile
+functions. Once this has been called, the same <tt>OggVorbis_File</tt>
+struct should be passed to all the libvorbisfile functions.</dd>
+<dt><i>initial</i></dt>
+<dd>Typically set to NULL.  This parameter is useful if some data has already been
+read from the file and the stream is not seekable. It is used in conjunction with <tt>ibytes</tt>.  In this case, <tt>initial</tt>
+should be a pointer to a buffer containing the data read.</dd>
+<dt><i>ibytes</i></dt>
+<dd>Typically set to 0.  This parameter is useful if some data has already been
+read from the file and the stream is not seekable. In this case, <tt>ibytes</tt>
+should contain the length (in bytes) of the buffer.  Used together with <tt>initial</tt></dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>0 indicates success</li>
+
+<li>less than zero for failure:</li>
+<ul>
+<li>OV_EREAD - A read from media returned an error.</li>
+<li>OV_ENOTVORBIS - Bitstream is not Vorbis data.</li>
+<li>OV_EVERSION - Vorbis version mismatch.</li>
+<li>OV_EBADHEADER - Invalid Vorbis bitstream header.</li>
+<li>OV_EFAULT - Internal logic fault; indicates a bug or heap/stack corruption.</li>
+</ul>
+</blockquote>
+<p>
+
+<a name="notes"></a>
+<h3>Notes</h3>
+<dl>
+
+<a name="winfoot"></a>
+<dt><b>[a] Windows and ov_open()</b><p>
+
+<dd>Under Windows, stdio file access is implemented in each of many
+variants of crt.o, several of which are typically installed on any one
+Windows machine.  If libvorbisfile and the application using
+libvorbisfile are not linked against the exact same
+version/variant/build of crt.o (and they usually won't be, especially
+using a prebuilt libvorbis DLL), <tt>FILE *</tt> handles cannot be
+opened in the application and then passed to vorbisfile to be used
+by stdio calls from vorbisfile's different version of CRT.  For this
+reason, using <a href="ov_open.html">ov_open()</a> under Windows
+without careful, expert linking will typically cause a protection
+fault.  Windows programmers should use <a
+href="ov_fopen.html">ov_fopen()</a> (which will only use libvorbis's
+crt.o) or <a href="ov_open_callbacks.html">ov_open_callbacks()</a>
+(which will only use the application's crt.o) instead.<p>
+
+This warning only applies to Windows and only applies to <a
+href="ov_open.html">ov_open()</a>.  It is perfectly safe to use <a
+href="ov_open.html">ov_open()</a> on all other platforms.<p>
+
+For more information, see the following microsoft pages on <a
+href="http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx">C
+runtime library linking</a> and a specific description of <a
+href="http://msdn2.microsoft.com/en-us/library/ms235460(VS.80).aspx">restrictions
+on passing CRT objects across DLL boundaries</a>.
+
+<p>
+
+<dt><b>[b] Threaded decode</b><p>
+<dd>If your decoder is threaded, it is recommended that you NOT call
+<tt>ov_open()</tt>
+in the main control thread--instead, call <tt>ov_open()</tt> in your decode/playback
+thread. This is important because <tt>ov_open()</tt> may be a fairly time-consuming
+call, given that the full structure of the file is determined at this point,
+which may require reading large parts of the file under certain circumstances
+(determining all the logical bitstreams in one physical bitstream, for
+example).  See <a href="threads.html">Thread Safety</a> for other information on using libvorbisfile with threads.
+<p>
+
+<dt><b>[c] Mixed media streams</b><p>
+<dd>
+As of Vorbisfile release 1.2.0, Vorbisfile is able to access the
+Vorbis content in mixed-media Ogg streams, not just Vorbis-only
+streams.  For example, Vorbisfile may be used to open and access the
+audio from an Ogg stream consisting of Theora video and Vorbis audio.
+Vorbisfile 1.2.0 decodes the first logical audio stream of each
+physical stream section.<p>
+
+<dt><b>[d] Faster testing for Vorbis files</b><p>
+<dd><a href="ov_test.html">ov_test()</a> and <a
+href="ov_test_callbacks.html">ov_test_callbacks()</a> provide less
+computationally expensive ways to test a file for Vorbisness, but
+require more setup code.<p>
+
+</dl>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2010 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>vorbisfile version 1.3.2 - 20101101</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>