[xiph-commits] r14360 - trunk/ogg/doc/libogg

giles at svn.xiph.org giles at svn.xiph.org
Fri Jan 4 12:11:22 PST 2008


Author: giles
Date: 2008-01-04 12:11:22 -0800 (Fri, 04 Jan 2008)
New Revision: 14360

Modified:
   trunk/ogg/doc/libogg/ogg_stream_packetin.html
   trunk/ogg/doc/libogg/ogg_stream_packetout.html
Log:
Document the memory ownership when passing ogg packets in and out.


Modified: trunk/ogg/doc/libogg/ogg_stream_packetin.html
===================================================================
--- trunk/ogg/doc/libogg/ogg_stream_packetin.html	2008-01-04 20:11:13 UTC (rev 14359)
+++ trunk/ogg/doc/libogg/ogg_stream_packetin.html	2008-01-04 20:11:22 UTC (rev 14360)
@@ -17,9 +17,16 @@
 
 <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
+<p>This function submits a packet to the bitstream for page 
+encapsulation. After this is called, more packets can be submitted,
+or pages can be written out.</p>
 
+<p>In a typical encoding situation, this should be used after filling a 
+packet with data.
+The data in the packet is copied into the internal storage managed by 
+the <a href="ogg_stream_state.html">ogg_stream_state</a>, so the caller
+is free to alter the contents of <i>os</i> after this call has returned.
+
 <br><br>
 <table border=0 color=black cellspacing=0 cellpadding=7>
 <tr bgcolor=#cccccc>

Modified: trunk/ogg/doc/libogg/ogg_stream_packetout.html
===================================================================
--- trunk/ogg/doc/libogg/ogg_stream_packetout.html	2008-01-04 20:11:13 UTC (rev 14359)
+++ trunk/ogg/doc/libogg/ogg_stream_packetout.html	2008-01-04 20:11:22 UTC (rev 14360)
@@ -17,9 +17,22 @@
 
 <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. Each successive call returns the next complete packet built from those 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. If the function returns 0, more data is needed and another page should be submitted. A non-zero return value indicates successful return of a packet.</p>
+<p>This function assembles a data packet for output to the codec 
+decoding engine. The data has already been submitted to the
+<a href="ogg_stream_state.html">ogg_stream_state</a> and broken
+into segments. Each successive call returns the next complete packet 
+built from those 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. If the function returns 0, more data is 
+needed and another page should be submitted. A non-zero return value 
+indicates successful return of a packet.</p>
+
+<p>The <i>op</i> is filled in with pointers to memory managed by
+the stream state and is only valid until the next call. The client
+must copy the packet data if a longer lifetime is required.</p>
+
 <br><br>
 <table border=0 color=black cellspacing=0 cellpadding=7>
 <tr bgcolor=#cccccc>
@@ -39,7 +52,8 @@
 <dt><i>op</i></dt>
 <dd>Pointer to the packet to be filled in with pointers to the new data. 
 This will typically be submitted to a codec for decode after this 
-function is called.</dd>
+function is called. The pointers are only valid until the next call
+on this stream state.</dd>
 </dl>
 
 



More information about the commits mailing list