On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote: > 2018-08-17 23:28 GMT+03:00 Michael Niedermayer <mich...@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@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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel