[FFmpeg-devel] [PATCH] fate/filter-video.mak: do not use bit-exact check for dnn_processing

[Martin Storsjö]

On Tue, 21 Jan 2020, Guo, Yejun wrote:

>
>
>> -----Original Message-----
>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
>> Martin Storsj?
>> Sent: Tuesday, January 21, 2020 4:38 AM
>> To: FFmpeg development discussions and patches <ffmpeg-devel at 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-bounces at ffmpeg.org] On Behalf
>> Of
>>>> Carl Eugen Hoyos
>>>> Sent: Monday, January 20, 2020 10:14 PM
>>>> To: FFmpeg development discussions and patches
>> <ffmpeg-devel at 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ö
>>>> <martin at 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