


Using a nifty tool in the repo called graph2dot, I generated a plot of each step in the process: The FFmpeg codebase is large and complex, and the filter above is fairly complicated as well. What was strange, however, was that non-transparent pixels were being affected. This indicated something was going wrong when processing transparent pixels. This bug only affected Stickers, which are GIFs with some transparent pixels. The buggy renditions were traced back to an FFmpeg command that we use to re-scale GIFs while retaining the original color palette: ffmpeg -i in.gif -filter_complex "scale=100:-1, split palettegen paletteuse" out.gif Unwilling to let the world go without pixel-perfect poop, I started hunting down the bug.

Notice that some parts of the image get stuck (eg, the top of this GIF)
