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

[Guo, Yejun]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of
> Martin Storsj?
> Sent: Wednesday, January 22, 2020 8:09 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
> 
> 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.

yes, I can just keep fate-filter-dnn_processing-halve_first_channel_float, and will
not change it in future.

The pixle format of the test is rgb24, there's no issue for endianess, and I've also
verified it on IBM PowerPC.

The only concern is the value of FUZZ for oneoff test, I think the default value 1
is enough for all the architectures, but I do not have one at hand for a real verification.

I'll send out the v2 patch, and heartily seek helps for a pre-push verification from whom have other systems except x86/linux. thanks.

> 
> 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".