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

[Michael Niedermayer]

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


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180818/887e8080/attachment.sig>