Re: [Lame-dev] dshow & version.h

[Alexander L. <Alexander@Leidinger.net>]

On 24 Feb, Mark Taylor wrote:
>> > 
>> > You are right, this would be the best way, if not a few problems. First
>> > of all, calling DLL routines directly adds some performance overhead.
>> > This is not a problem if we implement DLL as a COM object and force
>> > wrapper DLLs to use this COM object. The second problem is LAME itself.
>> > AFAIK there is still vaprintf(stderr,...) and exit calls instead of
>> 
>> I can only find exit calls in mpglib and the frontend, I've used
>>   grep -r exit . |grep -e "^.*\.[ch]:" | grep -v -e "^\./misc"
>> to locate exit calls.
>> 
> 
> Yes, all printf(stderr,...) calls at one point were removed from the
> encoding library, but a few may have crept back in.  We have some
> macros for this, ERRORF() and MSG().  The plan was to change these to
> function calls.  The default will be to do nothing, but the calling
> program can provide its own message handling functions (
> lame_set_msg_handler, lame_set_error_handler).  But whoever started on
> this work never finished.
> 
> The library does return error codes.  Right now if an error occurs,
> ERRORF() is called, and an error code is returned to the calling
> program.  non-negative return code means success, negative
> return codes (usually just a -1) mean an error.  The negative
> return codes could easily be expanded.
> 
>> 
>> Please mail me a list of elements in the gfp for which you want a
>> get/set function. A proposal for the name of the get/set function would
>> also be nice, e.g.
>> 
>> quality:  set_lame_general_encoding_quality
>> VBR_q  :  set_lame_VBR_size_to_quality_rating    (?)
>> 
> 
> Probably everything in lame_global_flags needs a lame_set and
> a lame_get.  I see no reason to name the function with anything
> other than the exact name of the variable.  
> 
> return_code = lame_set_quality(int val)
> return_code = lame_set_VBR_q(double val)
> 
> There was some debate about this a while ago, but the verdict
> was that all function arguments would be strongly typed.
> This is somewhat documented in the file "API".
> 
> As for the get_fuction, your suggestion seems good, something
> like:  
> 
> return_code = lame_get_quality(int *val)

It depends. If we use it, we have the possibility to raise an error if
the gfp isn't valid (e.g. NULL pointer). But this is the only error
condition I can think of for these get functions.

Bye,
Alexander.

-- 
            Yes, I've heard of "decaf." What's your point?

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7