[ogg-dev] Ogg bitwise.c bit tracking

Timothy B. Terriberry tterribe at email.unc.edu
Thu Feb 7 15:44:57 PST 2008

Ivo Emanuel Gonçalves wrote:
> And IF that kind of performance can be gained in libvorbis too, the
> question is, what are we waiting for?

I doubt the performance gain would be that large. Theora had the fun  
little situation where it was thunking into the big endian version of  
some bitpacker functions which were one-line calls to the little  
endian version. Because gcc seemed to be concerned that some dynamic  
library could override one and not the other, it went through the  
routine of saving old registers and setting up the PIC register two  
times, and then restoring everything on the way out two times. Hence  
almost half the time spent in the hundreds of thousands of calls to  
that function per frame was for mucking around with the stack in a  
one-line call that should've been inlined away anyway. And on top of  
that Theora had an additional wrapper to handle various problems with  
the libogg1 API when reading past the end of a packet, which added  
even more overhead.

Vorbis, on the other hand, calls the little endian versions of the  
functions directly and decodes far fewer bits per second, typically.  
Also, Ralph reported that x86-64 showed only a 7% speed-up in Theora  
with the above patch (presumably because of the much saner ABI), so  
architecture makes a big difference as well.

None of that means there aren't other very good reasons we should pull  
the bitpacker out of libogg that have nothing to do with speed. People  
seem to have a philosophical problem with linking to libogg when they  
want to mux Vorbis in non-Ogg containers, even though the only  
Ogg-specific parts of libogg are a single C file which compiles to a  
single object file smaller than 30K. The only people who actually care  
about something so small are embedded developers, who would use Tremor  
(with its own built-in bitpacker) anyway.

More information about the ogg-dev mailing list