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

Michael Niedermayer michaelni
Wed Mar 3 19:39:00 CET 2010


On Wed, Mar 03, 2010 at 11:47:09AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Mar 2, 2010 at 5:57 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Mar 02, 2010 at 05:51:30PM -0500, Ronald S. Bultje wrote:
> >> 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
> 
> I stand corrected, it's num_channels instead of n_samples. Why is
> that? Is there a case where the output would differ from the

its faster to iterate over a linear array than num_channels arrays in the
inner loop

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20100303/ca4edca7/attachment.pgp>



More information about the ffmpeg-devel mailing list