On Mon, Mar 16, 2015 at 12:41 AM, Michael Niedermayer <michae...@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 <michae...@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.ba...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
