mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2024-12-18 03:19:31 +02:00
dcc9454ab9
To trigger this bug, use `paletteuse=dither=bayer:bayer_scale=0`; you will see that adjacent pixel lines will use the same dither pattern, instead of being shifted from each other by 32 units (0x20). One way to demostrate the bug is: $ convert -size 64x256 gradient:black-white -rotate 270 grad.png $ echo 'P2 2 1 255 0 255' > bw.pnm $ ffmpeg -i grad.png -filter_complex 'movie=bw.pnm,scale=256x1[bw]; [0:v][bw]paletteuse=dither=bayer:bayer_scale=0' gradbw.png Previously: https://www.rm.cloudns.org/img/uploaded/0bd152c11b9cd99e5945115534b1bdde.png Now: https://www.rm.cloudns.org/img/uploaded/89caaa5e36c38bc2c01755b30811f969.png This was caused by passing inconsistent color vs (a,r,g,b) parameters to color_get(), and NBITS being 5 meaning actually hitting the same cache node does happen in this case, but ONLY if bayer_scale is zero. The fix is passing the correct color value to color_get(). Also added a previous-failing FATE test; image comparison of the first frame: Previously: https://www.rm.cloudns.org/img/uploaded/d0ff9db8d8a7d8a3b8b88bbe92bf5fed.png Now: https://www.rm.cloudns.org/img/uploaded/a72389707e719b5cd1c58916a9e79ca8.png (on this less synthetic test image, the bug basically causes noise from cache hits vs misses) Tested: FATE passes, which exercises this filter but at the default bayer_scale. Reviewed-by: Paul B Mahol <onemda@gmail.com> |
||
|---|---|---|
| .. | ||
| api | ||
| checkasm | ||
| fate | ||
| filtergraphs | ||
| ref | ||
| .gitignore | ||
| audiogen.c | ||
| audiomatch.c | ||
| base64.c | ||
| copycooker.sh | ||
| extended.ffconcat | ||
| fate-run.sh | ||
| fate-valgrind.supp | ||
| fate.sh | ||
| Makefile | ||
| md5.sh | ||
| refcmp-metadata.awk | ||
| reference.pnm | ||
| rotozoom.c | ||
| simple1.ffconcat | ||
| simple2.ffconcat | ||
| test.ffmeta | ||
| tiny_psnr.c | ||
| tiny_ssim.c | ||
| utils.c | ||
| videogen.c | ||
