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

[Sergey Lavrushkin]

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

> On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote:
> > 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
>
> I dont think we should change the "algorithm" to achive "bitexactness"
> we could of course but it feels like the wrong reason to make such a
> change. How its done should be choosen based on what is fast (and to a
> lesser extend clean, simple and maintainable)
>
>
>
> > 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.
>
> Its possible to compare to a reference, we do this in some other tests,
> but thats surely more work than just disabling teh specific tests or trying
> to nudge them a little to see if that makes nothing fall too close to n +
> 0.5
>
> >
> >
> > > 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.
>
> most things are possible
>

Hi,

I am having trouble reproducing this error. These tests are fine for 32-bit
VMs on
my computers. So the only thing I can do is to disable these tests for
these formats.
Otherwise, I need to test other changes somehow. Here is the patch, that
skips
pixfmts tests for these formats.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tests-Disables-pixfmts-tests-for-float-gray-formats.patch
Type: text/x-patch
Size: 8871 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180820/1f0819bf/attachment.bin>