[FFmpeg-devel] [PATCH] Make binkaudio work with ff_float_to_int16_interleave_c

Michael Niedermayer michaelni
Thu Mar 11 01:04:24 CET 2010


On Wed, Mar 10, 2010 at 06:03:43PM +0000, M?ns Rullg?rd wrote:
> Alex Converse <alex.converse at gmail.com> writes:
> 
> > On Wed, Mar 10, 2010 at 12:06 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >> Hi,
> >>
> >> On Wed, Mar 10, 2010 at 5:46 AM, Martin Storsj? <martin at martin.st> wrote:
> >>> The bink audio decoder produces distorted output if the
> >>> float_to_int16_interleave function happens to be implemented by
> >>> ff_float_to_int16_interleave_c. All other audio decoders using this
> >>> function have special casing for the case when float_to_int16_interleave
> >>> is implemented by ff_float_to_int16_interleave_c, adding a particular
> >>> bias and scale factor.
> >>
> >> Independent of the patch (I'm not maintainer), and maybe this is just
> >> me, but why is this the case? This just smells like BBBBUUUUUUGGGGGGG
> >> to me. Does the 1-cycle gain that you got through this really justify
> >> the real problems that quite apparently result from it?
> >>
> >
> > I agree with Ronald.
> >
> > ff_float_to_int16_interleave_c uses some 754 hacks to pull int16 out
> > of a float. most other implementations of this use special native
> > vectorized instructions.
> >
> > I'd like to see more audio decoders outputting in their native sample
> > format and getting converted to the target format with a better
> > audioconvert.c, particularly when the coders have optional postfilters
> > or bandwidth extensions.
> 
> I fully agree.  I don't know of a single hardware FPU without a fast
> float to int conversion instruction, and if you're running a floating

pre SSE x86
also ->int32 is not that good as that then needs cliping to int16

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

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/20100311/d2bbf135/attachment.pgp>



More information about the ffmpeg-devel mailing list