Vorbis dev - Jan 2001 - By design or a bug?

Happy new millenium!

Summary: I'm having a problem queueing up the ogg_packet results of
vorbis_analyze() for later writing to an .ogg stream.  The docs don't seem
to say if this is permissable or not.  Hence, I don't know if I'm using
the API incorrectly, or if this is an actual bug.

-----

Attached is a short patch to vorbis-tools/oggenc/encode.c (from CVS head,
01/01/01... I just wanted to type that :-) that gives strange behavior;
I'm not sure that I understand why.

The main encoding loop is the same except that I queue up Q_SIZE (10, in
this patch) ogg_packets -- the result of vorbis_analyze() -- before
sending them to the output stream.

It's a simple array of ogg_packet[Q_SIZE], that, when filled, loops over
the array and calls ogg_stream_packetin(), ogg_stream_pageout(), and
oe_write_page() (fwrites the resulting ogg_page to the output stream).
Then we begin to fill the array again.

Everything else in oggenc is the same -- no multithreading or anything.
I had to add 2 more control blocks (an if and a for), but left the
indenting they way it already is so that it would be a short patch; cope.

When Q_SIZE is 1, you effectively have the original oggenc, and everything
works fine.

When Q_SIZE > 1, the output is wrong (ignoring the problem that it will
drop up to (Q_SIZE-1) packets at the end; that's not the point here); you
can clearly hear its wrongness by playing the resulting .ogg file.  Try it
for yourself; the sample input that I've been using for testing is a short
~10 second clip:

        http://www.mpi.nd.edu/~jsquyres/vorbis/uh_ungawaa.wav

Is this by design, or a bug?  Is it not permissable to queue up
ogg_packets for later writing?  I didn't see any state that is stored in
the ogg_packet or ogg_stream_state that seemed to be related to successive
calls to vorbis_analyze() -- indeed, that would seem to be an abstraction
violation -- but there easily could be some things hidden in those structs
that I'm not aware of.

{+} Jeff Squyres
{+} squyres@cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"


<HR NOSHADE>
<UL>
<LI>TEXT/PLAIN attachment: encode_patch
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encode_patch
Type: application/octet-stream
Size: 2041 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010101/9d2094d1/encode_patch-0001.obj

On Mon, 1 Jan 2001, Jeff Squyres wrote:
> Summary: I'm having a problem queueing up the ogg_packet results of
> vorbis_analyze() for later writing to an .ogg stream.  The docs don't
> seem to say if this is permissable or not.  Hence, I don't know if
I'm
> using the API incorrectly, or if this is an actual bug.
I caught Monty on #vorbis, and he provided a quick answer -- ogg_packets
refer to their corresponding vorbis_blocks.  Hence, those have to be
queued up as well so that they're not overwritten with the next call to
vorbis_analysis_blockout().  A quick sanity check with code confirms that
queueing up vorbis_blocks with their corresponding ogg_packets does the
trick.  Good to know.

Just following up here so that it gets into the web archives...

Bummer for distributed encoding, though -- one more data structure to have
to send between machines.  Hmmm....

{+} Jeff Squyres
{+} squyres@cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.