The tremolo filter uses floating point internally, and uses multiplication factors derived from sin(fmod()), neither of which is bitexact for use with framecrc.
This fixes running this test with mingw/x86_32 binaries when run in wine on linux (unsure if the same issue is present when run on actual windows). In this case, a 1 ulp difference in the output from fmod() would end up in an output from the filter that differs by 1 ulp, but which makes the lrint() in swresample/audioconvert.c round in a different direction. --- This change requires uploading a new reference file. --- tests/fate/filter-audio.mak | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak index fed2644ccf..b1dcb9787a 100644 --- a/tests/fate/filter-audio.mak +++ b/tests/fate/filter-audio.mak @@ -189,7 +189,10 @@ fate-filter-stereotools: CMD = framecrc -i $(SRC) -frames:a 20 -af stereotools=m FATE_AFILTER-$(call FILTERDEMDECENCMUX, TREMOLO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-tremolo fate-filter-tremolo: tests/data/asynth-44100-2.wav fate-filter-tremolo: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav -fate-filter-tremolo: CMD = framecrc -i $(SRC) -frames:a 20 -af tremolo +fate-filter-tremolo: CMD = ffmpeg -i $(SRC) -frames:a 20 -af tremolo -f wav -f s16le - +fate-filter-tremolo: REF = $(SAMPLES)/filter/tremolo.pcm +fate-filter-tremolo: CMP = oneoff +fate-filter-tremolo: CMP_UNIT = s16 FATE_AFILTER-$(call FILTERDEMDECENCMUX, COMPAND, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-compand fate-filter-compand: tests/data/asynth-44100-2.wav -- 2.17.1 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
