[FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Sergey Lavrushkin]

2018-08-17 23:28 GMT+03:00 Michael Niedermayer <michael at niedermayer.cc>:

> On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote:
> > On 8/14/2018 1:23 PM, Michael Niedermayer wrote:
> > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote:
> > >>>
> > >>> Just use av_clipf instead of FFMIN/FFMAX.
> > >>
> > >>
> > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8.
> > >
> > > will apply
> > >
> > > thanks
> >
> > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be
> > tested for bitexact output. The gbrpf32 ones aren't, for example.
> > http://fate.ffmpeg.org/report.cgi?time=20180816131312&slot=
> x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx
>
> hmmmm
> i remember i had tested this locally on 32bit
> can something be slightly adjusted (like an offset or factor) to avoid any
> values becoming close to 0.5 and rounding differently on platforms ?

If not the tests should skip float pixel formats or try the nearest
> neighbor scaler
>

Can it really be the problem with scaler? Do all these failed test use
scaling?
Is not it the problem, that different platforms can give slightly different
results for
floating-point operations? Does input for the float format is somehow
generated
for these tests, so the input conversion is tested? Maybe it uses output
conversion first?
If it is the problem of different floating-point operations results on
different platforms,
maybe it is possible to use precomputed LUT for output conversion, so it
will give
the same results? Or is it possible to modify tests for the float format,
so it will
check if pixels of the result are just close to some reference.


> Sergey, can you look into this (its your patch) ? (just asking to make sure
> not eevryone thinks someone else will work on this)
>

Yes, I can, just need to know, what is possible to do to fix this issue,
besides skipping the tests.