Re: [libav-devel] [PATCH] FATE: use proper comparison mode in the lavr tests

[Martin Storsjö]

On Tue, 15 Oct 2013, Anton Khirnov wrote:


On Tue, 15 Oct 2013 11:47:53 +0300 (EEST), Martin Storsjö <mar...@martin.st> 
wrote:
On Tue, 15 Oct 2013, Anton Khirnov wrote:

---
Forgot to set FUZZ in the previous patch
---
tests/fate/libavresample.mak |   12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tests/fate/libavresample.mak b/tests/fate/libavresample.mak
index 516c6e6..0a9ed55 100644
--- a/tests/fate/libavresample.mak
+++ b/tests/fate/libavresample.mak
@@ -1,7 +1,7 @@
CROSS_TEST = $(foreach I,$(1),                                        \
                 $(foreach J,$(1),                                    \
                     $(if $(filter-out $(I),$(J)),                    \
-                         $(eval $(call $(2),$(I),$(J),$(3),$(4))),    \
+                         $(eval $(call $(2),$(I),$(J),$(3),$(4),$(5))),    \
                     )))

MIX_CHANNELS = 1 2 3 4 5 6 7 8
@@ -29,13 +29,15 @@ FATE_LAVR_RESAMPLE += fate-lavr-resample-$(3)-$(1)-$(2)
fate-lavr-resample-$(3)-$(1)-$(2): tests/data/asynth-$(1)-1.wav
fate-lavr-resample-$(3)-$(1)-$(2): CMD = avconv -i 
$(TARGET_PATH)/tests/data/asynth-$(1)-1.wav -ar $(2) -internal_sample_fmt $(3) 
-f $(4) -af atrim=end_sample=10240 -
fate-lavr-resample-$(3)-$(1)-$(2): CMP = oneoff
+fate-lavr-resample-$(3)-$(1)-$(2): CMP_UNIT = $(5)
+fate-lavr-resample-$(3)-$(1)-$(2): FUZZ = 4
fate-lavr-resample-$(3)-$(1)-$(2): REF = 
$(SAMPLES)/lavr/lavr-resample-$(3)-$(1)-$(2)
endef

-$(call CROSS_TEST,$(SAMPLERATES),RESAMPLE,s16p,s16le)
-$(call CROSS_TEST,$(SAMPLERATES),RESAMPLE,s32p,s32le)
-$(call CROSS_TEST,$(SAMPLERATES),RESAMPLE,fltp,f32le)
-$(call CROSS_TEST,$(SAMPLERATES),RESAMPLE,dblp,f64le)
+$(call CROSS_TEST,$(SAMPLERATES),RESAMPLE,s16p,s16le,u8)
+$(call CROSS_TEST,$(SAMPLERATES),RESAMPLE,s32p,s32le,u8)

Why is this using u8 as comparison for 16 and 32 bit integers? Because you
expect them to be bitexact? (Apparently there's no comparison mode for 32
bit integers?)

Not bitexact, just within one byte of each other. And yes, there is no 32bit int
mode. It should probably be added.

Right. But I guess it still would be better to use a s16l comparison 
instead of u8, since an u8 comparison with a +- 1 tolerance could tolerate 
misses of +- 256 of the actual value as well. Not that it's probable in 
accidental breakage, but it shouldn't cost us much extra to use the right 
one (especially for the 16 bit case where the right comparison exists).

// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel