[FFmpeg-devel] [PATCH] AAC: [PATCH] AAC: Add support for 7350Hz sampling rates
klaussfreire at gmail.com
Tue Mar 17 14:55:03 CET 2015
On Mon, Mar 16, 2015 at 12:41 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Mar 13, 2015 at 03:53:56PM -0300, Claudio Freire wrote:
>> On Fri, Mar 13, 2015 at 3:06 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Fri, Mar 13, 2015 at 02:34:08PM -0300, Claudio Freire wrote:
>> >> On Fri, Mar 13, 2015 at 12:39 PM, Nedeljko Babic
>> >> <Nedeljko.Babic at imgtec.com> wrote:
>> >> >> btw, i use the qemu from https://github.com/ssvb/QEMU.git
>> >> >> for mips as it at least years ago supported more extensions, i
>> >> >> would have guessed these where merged into main qemu but as you list
>> >> >> all the disables in the wiki, maybe i was guessing wrong
>> >> >
>> >> > I can confirm that main qemu supports both fpu and dspr1/dspr2 extension.
>> >> > Appropriate cpu model needs to be selected in order for the extension to be available.
>> >> > 74Kf supports all extensions, so adding "-cpu 74Kf" in "--target-exec" should enable fpu, dspr1 and dspr2 extensions.
>> >> As I was building on a more complete reply, the problem I have is with
>> >> the glibc, which is built with the soft float ABI.
>> >> As soon as I finish all the tests (they take a while) I'll post more
>> > they really shouldnt take much time
>> > a build (with ccache) should be quite fast and you only need to test
>> > make -j<num> fate-aac-s7350-encode
>> > can it be that theres some float rounding somewhere that leads to a
>> > different decission that causes this ?
>> Soft float is slow, add emulation and it's worse. The build is fast
>> enough, it's the tests the ones that are slow.
>> I'm going to try adding a hard-float version of the glibc in
>> opensuse's build service.
>> But first I want to get the patch that fixes mips tests verified.
> btw, if you cant reproduce this issue, maybe it would be best to
> just leave this one fate test out and continue, maybe one of the
> subsequent bug fixes will fix this too
I managed to reproduce it with a hardfloat build, so indeed it seems
like a float rounding issue.
Now it only needs solving.
More information about the ffmpeg-devel