Vorbis dev - Apr 2000 - Metadata followup

Once upon a time Monty said:
>id3v2 will not be a part of Vorbis. Ogg bistreams allow mixing streams of
any
>type, and there will be an XML stream type defined for metadata. This is a 
>better solution than id3 in just about every technical sense. The Ogg 
>bitstream code to support this already exists. 
Can you please elaborate? Is this functionality complete? The only
mention to metadata in the codebase that I can find is in codec.h:

/* ogg_packet is used to encapsulate the data and metadata belonging
   to a single raw Ogg/Vorbis packet *************************************/

Looking at ogg_packet its not clear to me what I need to do here. Do you
use some other nomenclature in the codebase?
>The comment fields in the Vorbis header are only for text comments, not 
>arbitrary metadata. 
I see the comments -- good thought!

--ruaok         Freezerburn! All else is only icing. -- Soul Coughing

Robert Kaye -- robert@moon.eorbit.net  http://moon.eorbit.net/~robert

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/

> Can you please elaborate? Is this functionality complete?
The functionality for mixing streams made of arbitrary packets is complete 
yes; this is the reason some of the libvorbis api calls begin with ogg_ as 
opposed to vorbis_

A 'packet' is just a buffer of a given length (it need not even be
octets, the
bit order within the octets is defined and can be generalized), but I don't
think we need to get into that ;-)
> The only
> mention to metadata in the codebase that I can find is in codec.h:
> 
> /* ogg_packet is used to encapsulate the data and metadata belonging
>    to a single raw Ogg/Vorbis packet *************************************/
My comments are, perhaps, written too much from the viewpoint of vorbis.  A 
packet is *any* chunk of data of any length.  You get to define what's in
'em.
> Looking at ogg_packet its not clear to me what I need to do here. Do you
> use some other nomenclature in the codebase?
It's an unstructured bitwise blob.  The bitstreams provide checksumming and
framing.  you know that out == in, and beginning and end are what they were
when the packet went in.  That's all.

The Ogg code for generic streaming right now is all about low level 
functionality; you still need to manually feed the pages in the proper order 
into the ogg_sync_XXXX abstraction...

On the decode side....

the ogg_sync_ functions track the physical bitstream and frame/seperate pages.
Pages are returned one-by-one.  Seperate streams are multiplexed at this level,
and each stream has a unique 'serial number'.  When pulling a page out,
you get
the stream serial number of the page too.  Right now it's up to you to
determine stream type based on initial headers and serial numbers; this could
be automated.

One sets un an ogg_stream 'object' for each stream type [serial number];
one
feeds pages of a stream type into the associated ogg_stream functions.  These 
functions break out your packets.  Beyond that, the packet is raw data wholly 
owned by the stream type and you can make it all up from there.

In Vorbis's case, the first packet (and the first page; page 1 contains only
this first packet so that it is small.  When multiplexing things, a header 
packet for each stream type has to come first) is an initial header declaring 
Vorbisness and a few attributes.  packet 2 is always the text comment fields, 
and packet 3 is the codebooks.

Monty

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/

Because I want to use vorbis to stream multiple tracks of
compressed audio in a game, I care a bit about its performance.
So today, once I had the basic functionality I needed, I
started benchmarking.  The app I have basically just uses
vorbisfile to decode a compressed stream as 44khz 16-bit PCM;
it's a win32 app compiled with Visual C++ 6.
I found that playback of one music stream took about 11% of 
my Athlon 500's CPU which seemed like a lot.

Of course, I was not worried about this, as real
hardcore optimizations should not be done until the system
is finalized.  But I wanted to get a good feel for where the
CPU time is spent, so I ran some profiles on some code.

I found one alarming thing -- 37% of the CPU time was being
spent in hypot(), in _vlpc_de_helper in lpc.c.  Apparently the
Visual C++ version of hypot is hideously slow... it was spending
all its time setting up rounding modes and calling all kinds of
funky math functions, ensuring some form of numeric
stability that we don't need.  So I changed the hypot to
a simple sqrt(a*a + b*b) and the code became drastically 
faster (as the compiler then just uses the chip's fsqrt 
instruction; hypot was calling some software sqrt thing).
I don't know whether gcc has similar issues but someone should
check this.

It also seemed like a lot of time was being spent in vorbisfile
converting float to int (as seen in the earlier discussion) and 
writing the samples to the output buffer.

I made two basic changes here.  One was using the fast integer 
conversion code that I posted last week (but inserted into
vorbisfile, not in the dct code as was being pondered earlier).
The other change was, I checked whether the endianness of the 
machine was the same as the output endianness that the user 
asks for.  If so, I use a loop that outputs each sample as a 
single 'short', which eliminates the bit shifting and masking
and half the write operations.  Because the user is almost 
always going to want the numbers back in their native
endianness, this is an effective optimization.

With these changes in place, my app runs almost twice as fast
as before.  And looking at the way things are set up, I'm 
pretty confident I could get at least another factor of 2 or 3
speed improvement out of the existing code when it comes time
to Optimize For Real.

I also noticed that, though some are compiling in win32 sometimes,
there doesn't seem to be an official vc6 project checked into the
tree.  I offer to check this in and maintain it if that is
acceptable (I'm going to be maintaining a vc6 project, so I might
as well share the effort.

Should I consider submitting a patch with these optimizations in
it?  The sqrt(a*a + b*b) seems like a no-brainer to include;
the other ones are more questionable, it just depends on how
much we care about performance at this stage.  What is the
procedure for submitting a patch, do I just email it to Monty?

Also, someone was talking earlier about assembly-language 
optimization of the code at some point in future.  One thing we 
have learned in game development is that there is not much point 
to writing assembly code for modern processors; you gain hardly
anything beyond what you can achieve from C.  Even in the cases
of special instruction sets (like Katmai or the 3DNow instructions)
there are C macros that you can use to do the right thing, most of
the time.  Speaking of which, 3DNow has an excellent fast inverse
square root function that would be just the sauce for replacing
that 1./hypot in _vlpc_de_helper.

   -Jonathan.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/