On Fri, 4 Mar 2016, Michael Niedermayer wrote:
On Fri, Mar 04, 2016 at 10:46:33PM +0100, Marton Balint wrote:
On Thu, 3 Mar 2016, Michael Niedermayer wrote:
On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote:
Signed-off-by: Marton Balint <c...@passwd.hu>
---
tests/fate/gapless.mak | 3 +++
tests/ref/fate/gapless-aac | 5 +++++
2 files changed, 8 insertions(+)
create mode 100644 tests/ref/fate/gapless-aac
seems to fail on x86-32
--- ffmpeg/tests/ref/fate/gapless-aac 2016-03-03 03:06:35.306048679 +0100
+++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100
@@ -1,5 +1,5 @@
9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1
-d3c3c4ea121b3f3b8a346a168d2fec0e
+d00bed4d4a83ce1addb92c075b2fcaaf
9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2
-d3c3c4ea121b3f3b8a346a168d2fec0e
+d00bed4d4a83ce1addb92c075b2fcaaf
63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3
Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details.
make: *** [fate-gapless-aac] Error 1
Hmm, it seems there is a tiny difference in the 145th sample of the
first decoded frame. I thought this is not supposed to happen with
the fixed point decoder. Anybody has any ideas?
in absence of better ideas
1:pepper the code with printf()
run on both x86-32 and 64
and diff to find te first difference
if that explains the problem then you are done
else goto 1
Okay, it seems that there are some architecture-dependant float-double
rounding errors at compile time and the sinewin tables are generated at
runtime, so as far as I see this will no be bitexact on all platforms...
I think I'll just come up with another test which does not involve the
actual data, only the frame metadata, that should be enough for checking
gapless results.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
