[FFmpeg-devel] [PATCH] unscaled float 2 int conversion

[Michael Niedermayer]

On Sat, May 03, 2008 at 04:17:57PM +0200, Benjamin Larsson wrote:
> Michael Niedermayer wrote:
> > On Sat, May 03, 2008 at 02:34:55PM +0200, Benjamin Larsson wrote:
> >> $topic
> >>
> >> While this might not be the fastest method, this could be useful in some
> >> cases. For example when it is not trivial and cheap to convert the
> >> floats to the proper representation. The wma decoder is one of those cases.
> > 
> > I dont know what you are talking about, wma is a normal MDCT codec and i dont
> > see why it would require a seperate float2int16 routine.
> > Either this is better for all MDCT codecs or none.
> 
> Well when I tried the last time I did't get it to work, there was some
> overlap issue that wasn't trivial to sort out. 

You just add 384 or what it was after the windowing/overlap.


> Anyway I don't like this
> scaling stuff to much as it complicates the code and only old platforms
> might have benefited from it. 

Its the "old" / less powerfull systems where it matters most, for a 
"new" powerfull desktop system it really doesnt matter much if its
round() lrintf() or SIMD. There are after all just 44100*channels samples
per second to convert ...


> And if/when we get a new audio api going
> then it complicate matters if codecs are allowed to output scaled samples.

One thing at a time please. This patch was about adding a duplicated
float2int16() not adding that hardly complicates the audio API IMHO.


> 
> > And benchmarks would be required as well to see if this is faster or slower
> > than the extra + 384 or what it was.
> 
> The wma patch is a resend on an ok'd patch from before.

I dont remember, do you know the subj/date of it?


> 
> Anyway, I would like to use this unscaled function for the dca decoder
> that currently is broken when not using simd. I don't really care about
> the wma code but this would be nice to have for dca.

We have a float2int16 function, adding another one needs some justification
and benchmarks. We need to fully understand what advantages and disadantages
this choice has.
We really have 3 choices
1. use the existing code
2. add a second function and use it in some code
3. replace the existing function by the proposed one

a disadantages for 2. is that we would have 2 functions
a advantages for 3. is that its simpler due to less complex scaling/bias
The speed effect of thes choices is unknown and has to be found out before
a choice can be made

It shouldnt be hard to write a small program to benchmark lrintf()/round()
SIMD/the bias trick float->int code/
(and likely someone already did such benchmark so just finding that might
 be even easier)

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20080503/a4ec7d3e/attachment.pgp>