[FFmpeg-devel] Merging the fixed point WMA decoder

Michael Niedermayer michaelni
Sat Dec 1 03:46:35 CET 2007

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?


>  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>

More information about the ffmpeg-devel mailing list