On Tue, 21 Jan 2020, Guo, Yejun wrote:
-----Original Message-----
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Martin Storsj?
Sent: Tuesday, January 21, 2020 4:38 AM
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use bit-exact
check for dnn_processing
On Mon, 20 Jan 2020, Guo, Yejun wrote:
-----Original Message-----
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
Of
Carl Eugen Hoyos
Sent: Monday, January 20, 2020 10:14 PM
To: FFmpeg development discussions and patches
<ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use
bit-exact
check for dnn_processing
Am Mo., 20. Jan. 2020 um 14:25 Uhr schrieb Martin Storsjö
<mar...@martin.st>:
Keep in mind that ideally, you shouldn't be changing the reference files
in the separate samples directory incrementially; ideally they should be
fairly static.
Since not everybody is a native speaker:
You cannot change reference files once they are used by fate, they have
to be static and remain where they are.
thanks Carl.
Just had a chance to test on IBM PowerPC (big end) and found the new gray
float test fails,
the reason is that the reference file is generated in little end machine and
grayf32 contains 4 bytes.
Just FWIW, for such cases, you should add something like "-pixfmt
grayf32le", so that the output is independent of the host endianness and
set e.g. CMP_UNIT=f32 and e.g. FUZZ=<value>, to make the oneoff test
actually do the right thing, otherwise you'd just compare individual bytes
in the float representation.
thanks Martin, I understand it now.
so, just to make the reference files small, I'll remove the grayf32 test
in V2 patch if no other comments, thanks.
Removing one test sounds fine, and keeping one test with an external
reference file in the samples directory sounds good to me - assuming that
the reference output is stable and won't change in the forseeable future,
and that you manage to get the test stable across architectures and
different endianness.
If it takes time to get the test to that point, I would suggest reverting
the existing two tests for now.
// Martin
_______________________________________________
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".
