Message ID | CAAeE=qoiZ-KVmG1oJP8RnheK5=p9s9t8utst1JbFsVrEbMn_UA@mail.gmail.com |
---|---|
State | New |
Headers | show |
Hello, 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. > > What is the conversion function which create "problem" in tests ? Martin
On Mon, Aug 20, 2018 at 11:27:05PM +0300, Sergey Lavrushkin wrote: > 2018-08-18 23:20 GMT+03:00 Michael Niedermayer <michael@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@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 [...]
> > > 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 > > I'm not against, removing these tests for now, But maybe to make tests simpler, we can use/add bit exact conversion for uint8 to float, we can generate a LUT without float calc and for uint16 to float, we can add a uint16 to float conversion without float calc, or maybe, generate a LUT in bit exact mode (probably faster, if it's acceptable to have a LUT for 16bit entries) If the bit exact mode is much slower than the "float" version we can keep both, in order to use the bit exact for various tests and use it as reference in order to compare bit exact and "float" conv for each func. I can send patch for this, if need. Martin
Martin Vignali wrote: >But maybe to make tests simpler, we can use/add bit exact >conversion for uint8 to float, we can generate a LUT without >float calc and for uint16 to float, we can add a uint16 to >float conversion without float calc, or maybe, generate a LUT >in bit exact mode (probably faster, if it's acceptable to have >a LUT for 16bit entries) In my experience, a LUT in bit exact mode is indeed faster. To me the proposed addition would be useful. And I guess LUTs for 16-bit entries will become necessary anyway at some point... Thank you! Reto
On Wed, Aug 22, 2018 at 10:20:53AM +0200, Martin Vignali wrote: > > > > > 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 > > > > > I'm not against, removing these tests for now, > > But maybe to make tests simpler, we can use/add bit exact conversion > for uint8 to float, we can generate a LUT without float calc > and for uint16 to float, we can add a uint16 to float conversion without > float calc, or maybe, generate a LUT in bit exact mode (probably faster, if > it's acceptable to have a LUT for 16bit entries) I think before you design everything around a non float based convertion it would make sense to evaluate the speed of SIMD for the convertion. so all the choices are understood > > If the bit exact mode is much slower than the "float" version we can keep > both, this is possible, it is not ideal though as the tested and used in practice code path differs then. Of course a bit exact version does make sense either way. As some people probably want scaling to be bitexact > in order to use the bit exact for various tests > and use it as reference in order to compare bit exact and "float" conv for > each func. > > I can send patch for this, if need. > > Martin > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > But maybe to make tests simpler, we can use/add bit exact conversion > > for uint8 to float, we can generate a LUT without float calc > > and for uint16 to float, we can add a uint16 to float conversion without > > float calc, or maybe, generate a LUT in bit exact mode (probably faster, > if > > it's acceptable to have a LUT for 16bit entries) > > I think before you design everything around a non float based convertion > it would make sense to evaluate the speed of SIMD for the convertion. > so all the choices are understood > > > > > > If the bit exact mode is much slower than the "float" version we can keep > > both, > > this is possible, it is not ideal though as the tested and used in practice > code path differs then. Of course a bit exact version does make sense > either > way. As some people probably want scaling to be bitexact > > Having func too much complicated to test, have more chance to make func not tested at all Bit exact mode is convenient for testing inside ffmpeg, but also useful outside, for example to be sure transcoding pipeline still give the same output (when i can, i prefer to use this even if the conv is slower, because is more reliable). Following your comments, i propose for a first step to add bit_exact mode for float <-> uint8/16 where i can, keeping the current func (adding a test for SWS_BIT_EXACT, in order to choose the right func) In a second step, test simd for "float" version. If using SIMD (or not), we can have faster conv, using the "float" method, we keep each func otherwise we remove the non bit-exact version, and add a comment in the code. If we keep both func, we can make a test func by func, comparing bit exact with non bit-exact, in order to be sure, both way to make the conversion have similar result. Martin
From a92e6965f9c328fcaa18460ac9da975748272e0a Mon Sep 17 00:00:00 2001 From: Sergey Lavrushkin <dualfal@gmail.com> Date: Mon, 20 Aug 2018 23:14:07 +0300 Subject: [PATCH] tests: Disables pixfmts tests for float gray formats. --- tests/fate-run.sh | 4 ++-- tests/ref/fate/filter-pixfmts-copy | 2 -- tests/ref/fate/filter-pixfmts-crop | 2 -- tests/ref/fate/filter-pixfmts-field | 2 -- tests/ref/fate/filter-pixfmts-fieldorder | 2 -- tests/ref/fate/filter-pixfmts-hflip | 2 -- tests/ref/fate/filter-pixfmts-il | 2 -- tests/ref/fate/filter-pixfmts-null | 2 -- tests/ref/fate/filter-pixfmts-scale | 2 -- tests/ref/fate/filter-pixfmts-transpose | 2 -- tests/ref/fate/filter-pixfmts-vflip | 2 -- 11 files changed, 2 insertions(+), 22 deletions(-) diff --git a/tests/fate-run.sh b/tests/fate-run.sh index aece90a01d..e8d71707b0 100755 --- a/tests/fate-run.sh +++ b/tests/fate-run.sh @@ -288,8 +288,8 @@ pixfmts(){ in_fmts=${outfile}_in_fmts # exclude pixel formats which are not supported as input - $showfiltfmts scale | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_in_fmts - $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_out_fmts + $showfiltfmts scale | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); if (fmt !~ /grayf32.e/){ print fmt } }' | sort >$scale_in_fmts + $showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); if (fmt !~ /grayf32.e/){ print fmt } }' | sort >$scale_out_fmts comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts $showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$in_fmts diff --git a/tests/ref/fate/filter-pixfmts-copy b/tests/ref/fate/filter-pixfmts-copy index 5385036a82..013b33f1c0 100644 --- a/tests/ref/fate/filter-pixfmts-copy +++ b/tests/ref/fate/filter-pixfmts-copy @@ -47,8 +47,6 @@ gray16be 08d997a3faa25a3db9d6be272d282eef gray16le df65eb804360795e3e38a2701fa9641a gray9be 6382a14594a8b68f0ec7de25531f9334 gray9le 4eb1dda58706436e3b69aef29b0089db -grayf32be f3bf178835f8146aa09d1da94bba4d8a -grayf32le fb6ea85bfbc8cd21c51fc0e110197294 monob 8b04f859fee6a0be856be184acd7a0b5 monow 54d16d2c01abfd72ecdb5e51e283937c nv12 8e24feb2c544dc26a20047a71e4c27aa diff --git a/tests/ref/fate/filter-pixfmts-crop b/tests/ref/fate/filter-pixfmts-crop index ae48c2bf42..750ea27404 100644 --- a/tests/ref/fate/filter-pixfmts-crop +++ b/tests/ref/fate/filter-pixfmts-crop @@ -47,8 +47,6 @@ gray16be 38f599da990224de86e3dc7a543121a9 gray16le 9ff7c866bd98def4e6c91542c1c45f80 gray9be 8ffcb18d699480f55414bfc21ab33321 gray9le 4d1932d4968a248584f5e39c25f1dd43 -grayf32be cf40ec06a8abe54852b7f85a00549eec -grayf32le b672526c9da9c8959ab881f242f6890a nv12 92cda427f794374731ec0321ee00caac nv21 1bcfc197f4fb95de85ba58182d8d2f69 p010be 8b2de2eb6b099bbf355bfc55a0694ddc diff --git a/tests/ref/fate/filter-pixfmts-field b/tests/ref/fate/filter-pixfmts-field index 857ded1c41..4fdc214781 100644 --- a/tests/ref/fate/filter-pixfmts-field +++ b/tests/ref/fate/filter-pixfmts-field @@ -47,8 +47,6 @@ gray16be e1700e056de9917744a7ff4ab2ca63fd gray16le 338de7ac5f7d36d5ad5ac2c8d5bbea68 gray9be 25e50940fa300a8f09edfb6eba4fd250 gray9le 1146cfc1b92bfd07ed238e65ffcd134f -grayf32be 72fbfa47b2863658a8a80d588f23b3e7 -grayf32le 6b856bdbf2a2bfcd2bc7d50f109daaf0 monob 2129cc72a484d7e10a44de9117aa9f80 monow 03d783611d265cae78293f88ea126ea1 nv12 16f7a46708ef25ebd0b72e47920cc11e diff --git a/tests/ref/fate/filter-pixfmts-fieldorder b/tests/ref/fate/filter-pixfmts-fieldorder index fc003457fc..7fc158b0af 100644 --- a/tests/ref/fate/filter-pixfmts-fieldorder +++ b/tests/ref/fate/filter-pixfmts-fieldorder @@ -47,8 +47,6 @@ gray16be 293a36548ce16543494790f8f7f76a05 gray16le 84f83f5fcbb5d458efb8395a50a3797e gray9be ec877f5bcf0ea275a6f36c12cc9adf11 gray9le fba944fde7923d5089f4f52d12988b9e -grayf32be 1aa7960131f880c54fe3c77f13448674 -grayf32le 4029ac9d197f255794c1b9e416520fc7 rgb0 2e3d8c91c7a83d451593dfd06607ff39 rgb24 b82577f8215d3dc2681be60f1da247af rgb444be 1c3afc3a0c53c51139c76504f59bb1f4 diff --git a/tests/ref/fate/filter-pixfmts-hflip b/tests/ref/fate/filter-pixfmts-hflip index e97c185f6e..70a43d9959 100644 --- a/tests/ref/fate/filter-pixfmts-hflip +++ b/tests/ref/fate/filter-pixfmts-hflip @@ -47,8 +47,6 @@ gray16be cf7294d9aa23e1b838692ec01ade587b gray16le d91ce41e304419bcf32ac792f01bd64f gray9be ac8d260669479ae720a5b6d4d8639e34 gray9le 424fc581947bc8c357c9ec5e3c1c04d1 -grayf32be a69add7bbf892a71fe81b3b75982dbe2 -grayf32le 4563e176a35dc8a8a07e0829fad5eb88 nv12 801e58f1be5fd0b5bc4bf007c604b0b4 nv21 9f10dfff8963dc327d3395af21f0554f p010be 744b13e44d39e1ff7588983fa03e0101 diff --git a/tests/ref/fate/filter-pixfmts-il b/tests/ref/fate/filter-pixfmts-il index a006fc19a3..ba06851e24 100644 --- a/tests/ref/fate/filter-pixfmts-il +++ b/tests/ref/fate/filter-pixfmts-il @@ -47,8 +47,6 @@ gray16be 92c3b09f371b610cc1b6a9776034f4d0 gray16le 1db278d23a554e01910cedacc6c02521 gray9be ed7db5bb2ddc09bc26068c8b858db204 gray9le 2ec9188f0dcfefef76a09f371d7beb8e -grayf32be f36197c9e2ef5c50a995e980c1a37203 -grayf32le 8bf3d295c3ffd53da0e06d0702e7c1ca monob faba75df28033ba7ce3d82ff2a99ee68 monow 6e9cfb8d3a344c5f0c3e1d5e1297e580 nv12 3c3ba9b1b4c4dfff09c26f71b51dd146 diff --git a/tests/ref/fate/filter-pixfmts-null b/tests/ref/fate/filter-pixfmts-null index 5385036a82..013b33f1c0 100644 --- a/tests/ref/fate/filter-pixfmts-null +++ b/tests/ref/fate/filter-pixfmts-null @@ -47,8 +47,6 @@ gray16be 08d997a3faa25a3db9d6be272d282eef gray16le df65eb804360795e3e38a2701fa9641a gray9be 6382a14594a8b68f0ec7de25531f9334 gray9le 4eb1dda58706436e3b69aef29b0089db -grayf32be f3bf178835f8146aa09d1da94bba4d8a -grayf32le fb6ea85bfbc8cd21c51fc0e110197294 monob 8b04f859fee6a0be856be184acd7a0b5 monow 54d16d2c01abfd72ecdb5e51e283937c nv12 8e24feb2c544dc26a20047a71e4c27aa diff --git a/tests/ref/fate/filter-pixfmts-scale b/tests/ref/fate/filter-pixfmts-scale index 05879ee3c7..559355be49 100644 --- a/tests/ref/fate/filter-pixfmts-scale +++ b/tests/ref/fate/filter-pixfmts-scale @@ -47,8 +47,6 @@ gray16be 32891cb0928b1119d8d43a6e1bef0e2b gray16le f96cfb5652b090dad52615930f0ce65f gray9be 779dec0c6c2df008128b91622a20daf8 gray9le fa87a96ca275f82260358635f838b514 -grayf32be 5e4c715519f53c15f1345df90481e5f5 -grayf32le 2ff1b84023e820307b1ba7a9550115bc monob f01cb0b623357387827902d9d0963435 monow 35c68b86c226d6990b2dcb573a05ff6b nv12 b118d24a3653fe66e5d9e079033aef79 diff --git a/tests/ref/fate/filter-pixfmts-transpose b/tests/ref/fate/filter-pixfmts-transpose index 44644099c6..78218cda4e 100644 --- a/tests/ref/fate/filter-pixfmts-transpose +++ b/tests/ref/fate/filter-pixfmts-transpose @@ -47,8 +47,6 @@ gray16be 4aef307021a91b1de67f1d4381a39132 gray16le 76f2afe156edca7ae05cfa4e5867126e gray9be 2c425fa532c940d226822da8b3592310 gray9le bcc575942910b3c72eaa72e8794f3acd -grayf32be 823288e1ec497bb1f22c070e502e5272 -grayf32le 6e9ec0e1cac3617f3041e681afd2c575 nv12 1965e3826144686748f2f6b516fca5ba nv21 292adaf5271c5c8516b71640458c01f4 p010be ad0de2cc9bff81688b182a870fcf7000 diff --git a/tests/ref/fate/filter-pixfmts-vflip b/tests/ref/fate/filter-pixfmts-vflip index 51628f14ce..3cb99e7d8d 100644 --- a/tests/ref/fate/filter-pixfmts-vflip +++ b/tests/ref/fate/filter-pixfmts-vflip @@ -47,8 +47,6 @@ gray16be 29f24ba7cb0fc4fd2ae78963d008f6e6 gray16le a37e9c4ea76e8eeddc2af8f600ba2c10 gray9be dda11d4ffd62b414012ffc4667fb4971 gray9le 159bf6482d217b2b8276eb2216cd7a09 -grayf32be c1ba5943a0d24d70e6a280f37e4f4593 -grayf32le 8e6c048a5b3b8b26d3a5ddfce255f3f6 monob 7810c4857822ccfc844d78f5e803269a monow 90a947bfcd5f2261e83b577f48ec57b1 nv12 261ebe585ae2aa4e70d39a10c1679294 -- 2.14.1