[vorbis-dev] Slightly OT: Vorbis encoding benchmarks

[Brian Hook]

> Does this mean that oggenc should periodically load big 
> chunks of the PCM data from disk into memory?  Or would 
> benchmarkers really want an oggenc flag that forces it to 
> preload the whole WAV into memory and buffer all of the 
> Vorbis output until the end?

If I were doing this, I would add a command line parameter like:

-readbuffer X: Size of the read buffer for encoding.  The default is
<1?>.  Values can range from 1 to <whatever> and are specified in
megabytes.  A parameter of "max" will attempt to read the entire file
into memory.

-deferwrites [yes|no]: if "yes", then the final output will be buffered
in RAM until the 

So for a benchmark, you'd do something like:

oggenc -readbuffer max -deferwrites yes benchmark.wav

Which would process benchmark.wav in one big swoop, writing to disk only
at the very end.  The timer also break it down into total processing
time and actual encoding time.  I'm real curious how a G4 stacks up
against an UltraSparc, Alpha, P4, or AthlonXP.  Would be interesting
data.  Are there any AltiVec, SSE, etc. optimizations in the encoders
right now?

However, you could go the other route, e.g. someone that wants oggenc to
run as a low priority task that doesn't consume many resources:

oggenc -readbuffer 1 -deferwrites no *.wav

Which would process all .wav files in the directory, in 1MB chunks, and
writing to disk after processing each chunk.

Oh, and that's another thing -- we'd have to find a reference .WAV file
for encoding.  Something REAL big and that is a worst case type
situation.

Brian

<p><p>--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.