At 07:58 PM 6/5/00 -0400, you wrote:
>>I had to modify the Vorbis CVS slightly to quiet down the encoder. The
>culprit in this case was res0.c spewing out who-knows-what, ruining the
>possibility of on-screen progress reporting. I suggest an #ifdef DEBUG
>around the noisy lines in res0.c, but in general, if the library is going
>to have useful information to report to the app, we need a standard
>messaging system. Perhaps
>>struct
>{
> void (*msg_to_lib) (void *data, int size);
> void (*msg_to_app) (void *data, int size);
>} ov_msg;
This would be nice if the library were designed to be dumping stuff out to
std(out|err), but this bit in res0.c is just debugging code that Monty
forgot to remove. It'll go away - or you can just delete it locally, as
you've done.
If you look through the code, you'll see there are a number of other
sections which produce output that are ifdef'd out, similarly.
Monty intends (I believe) to eventually change the library to return more
specific error codes (rather than just a generic 'error' result), which
will replace most of the reasons you might want to produce output from the
middle of the encoder library.
There is one place, however, where the message-printing does need to be
overhauled. Vorbisfile prints errors to stderr, which often isn't going to
be visible (or might not even exist, on win32 for example). I was intending
to go through and change things over in vorbisfile to use some generic
error handling function pointer, but exams intervened.
Unlike libvorbis, vorbisfile is meant to be a very simple and high-level
interface, so simply printing error messages is a better choice than
returning error codes that have to be handled. We want to keep it simple.
There isn't any need for the app to send a message to the library - all we
ever need is to produce output from the library - a single function pointer.
Michael
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/