Further ffmpeg optimizations

[alphapapa]

From https://www.reddit.com/r/linux/comments/aa1jzm/bashcaster_an_actually_simple_screen_recorder_for/ecozlfj/

Suggestions for gif recording:

use the mpdecimate filter to remove duplicate frames. In a screen recording there can be huge number of duplicate frames, especially if it's mostly showing a still image of a desktop. Video games can have frame drops, which manifest as duplicate frames in recodings. This should reduce the file size of the resulting gif significantly.

use bayer dithering, which will yield another signficant size reduction.

In a 10 second desktop test recording that I converted to a gif, these two methods lead to a file size reduction of 89% (!) when compared to a gif that just used a plain pallettegen and palletteuse filter complex with no other additions.

I usually use something like this to create gifs:

ffmpeg -i input.mp4 -vsync 0 -filter_complex "[0:v] scale=-1:360,mpdecimate,fps=15,split [a][b];[a] palettegen=max_colors=64 [p];[b][p] paletteuse=dither=bayer:bayer_scale=5" output.gif

[alphapapa]

More: https://www.reddit.com/r/linux/comments/aa1jzm/bashcaster_an_actually_simple_screen_recorder_for/ecph8i2/

In my not very extensive experience, the main gifsicle software isn't all that useful as the -O3 option doesn't help all that much and the gifsicle developer seems to have abandoned the project or is at least ignoring pull requests, including a very important one that implements lossy compression. Lossy compression is what will really help with gif size in my experience and to use it you have to compile this fork from source which is obviously not ideal from a user perspective, but it works. I personally don't know any other Linux tool that does lossy GIF compression, so it's sad to see gifsicle in such a state.

I'm pretty sure that gifsicle doesn't remove duplicate frames, my testing hasn't shown the kind of size reduction that would follow and the man page doesn't mention duplicate frame removal at all. And personally I'd trust FFmpeg to do a better job of optimisation anyway, since it's doing its thing with the original video material and not working with something that's already been output to a lossy format.

As for dithering artifacts, at least for Bayer it seems to depend on the type of video material used. Using the highest level (5) of Bayer dithering on a simple desktop recording of moving the mouse around and opening a context menu, I didn't notice any artifacts at all and the file size was half in comparison to FFmpeg's default dithering method (sierra2_4a). Bayer makes a tradeoff between color banding and the kind of cross patterned dithering artifacts GIF is known for. Examples:

sierra2_4a (default), 5.2 MB https://i.imgur.com/L7g893B.gif

bayer_scale 1, 4.0 MB https://i.imgur.com/qa6loW8.gif

bayer_scale 2, 3.8 MB https://i.imgur.com/Ero2x71.gif

bayer_scale 3, 3.4 MB https://i.imgur.com/JtwBKhp.gif

bayer_scale 4, 3.1 MB https://i.imgur.com/vHqEvWR.gif

bayer_scale 5, 2.9 MB https://i.imgur.com/wJ7jW6Y.gif

As you can see, the higher the bayer_scale value, the more banding and the lower the file size. And the Bayer dithering is also the only one that has a knob to turn at all, the others don't have any settings to them.

All in all, dithering probably warrants more testing for what's best with various kinds of material. But sierra2_4a seems to look fine for most content and is probably the default for a reason.