[FFmpeg-devel] Merging the fixed point WMA decoder

[Michael Niedermayer]

On Wed, Nov 28, 2007 at 01:56:43PM -0500, Michael Giacomelli wrote:
> I'd like to start working on merging the fixed point wma decoder back into
> ffmpeg as soon as my other projects permit.  I have some questions about how
> to do this:
> 
> 1)  We don't really have much fixed point transform or dsputil code in
> place.  I've written some that works fine for this particular codec, but
> inserting it into ffmpeg is unclear to me.  Is it ok to make a
> wmaprecision.h file and import it into dsputil.c and elsewhere so that I can

no, a #include "wmaprecision.h" in dsputil.c/h is not ok


> #define the correct function calls there for things like
> vector_fmul_reverse, CMUL, etc?  Or should the wma codec somehow overwrite
> those function pointers and defines if needed during it's init?
> 

> 2)  Although most of the codec is pretty easy to make both fixed and fp just
> by playing with type defs and redefining what mul(), CMUL, etc does, theres
> some parts where it is not.  Is it acceptable to define function_fixed and
> function_float for these cases?

yes


>  Also, it is frequently necessary to rescale
> fixed point values in the middle of functions.  Is it acceptable to #define
> blocks in and out in the middle of a function?

no unless it absolutely needed
also the amount of rescalng should be kept to a minimum

and it might be worth it to write a high precission/slow and
low precission/fast fixed point implementation of some parts


> 
> 3)  I made a number of changes to how the codec works in order to better
> accommodate slower embedded processors, mostly in the form of using lookup
> tables and making better use of memory so that more could be loaded into
> small ondie RAM.  As far as I can tell, none decrease the accuracy of the
> codec.  Is there any objection to me merging these in as well?

all changes unlrelated to float->fixed must be in seperate patches also
if you can split the float->fixed on a per function base or other that would
simplify my reviewing work as well as reduce the number of resubmit
and review iterations (->less work for you as well)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071201/8c384ba7/attachment.pgp>