On Mon, Aug 20, 2018 at 11:27:05PM +0300, Sergey Lavrushkin wrote: > 2018-08-18 23:20 GMT+03:00 Michael Niedermayer <mich...@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 <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 > > > > Hi, > > I am having trouble reproducing this error. These tests are fine for 32-bit > VMs on > my computers.
yes, i had the same problem when i initially tested the code, it locally works on 32bit must be the exact platform or compiler ... > 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. in absence of another solution this should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
