[FFmpeg-devel] [PATCH] audio conversion clipping/overflows

[Michael Niedermayer]

On Tue, Mar 02, 2010 at 05:51:30PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Mar 2, 2010 at 6:36 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Mar 01, 2010 at 09:18:58AM -0500, Ronald S. Bultje wrote:
> >> float 1.0 rounds to int INT_MIN (whatever int size). This leads to
> >> considerable audio clipping artifacts.
> >>
> >> Attached patch is a lame attempt of mine to fix this. It probably
> >> makes the code slower, so sue me. :-).
> >
> >> ?libavcodec/audioconvert.c | ? 18 ++++++++++++------
> >> ?libavutil/common.h ? ? ? ?| ? 11 +++++++++++
> >> ?2 files changed, 23 insertions(+), 6 deletions(-)
> >> 3cbfbc44e4362ec7017ebdc358b3021319023bf1 ?aconv.patch
> >
> > ok but you know this needs optimizations
> 
> Well, yeah. I was wondering why the whole thing is constructed as:
> 
> for (n=0;n<n_samples;n++) {
>   if (from==.. && to=..) CONV...;
>   else if .. etc.
> }
> 

its not constructed like that


> Instead of the more logical pix_fmt way, i.e. a table of conversion
> functions, some of which could optionally be SIMD'ified (e.g.
> float<->int16)?
> 
> > also if you apply this, make sure you remove the cliping from every decoder
> > that matches SAMPLE_FMT_FLT
> 
> OK, separate commit OK or same? I know this affects SIPRO and QCELP at

whichever way you prefer


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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20100302/c92e01e2/attachment.pgp>