[FFmpeg-devel] Lossy GIF encoding

Paul B Mahol onemda at gmail.com
Fri Feb 15 18:50:31 EET 2019

On 2/15/19, Kornel <mailinglist at geekhood.net> wrote:
>>> Alternatively, would it be OK to create a separate codec just for
>>> lossy compression? I would create a new GIF codec, define it under a
>>> new name, and declare it always takes AV_PIX_FMT_RGB24 or
>>> AV_PIX_FMT_RGBA. Is that a good approach?
>> This sounds more like something that belongs in libswscale (RGBA ->
>> PAL8 conversion) or could be done with a filter. An option like
>> ImageMagick's -fuzz could be added to the PAL8 quantizer in sws
> Unfortunately, the lossy technique depends on a layering violation.
> The lossy compression alters each pixel in the image based on current,
> precise state of the LZW dictionary. Without doing both LZW and remapping at
> the same time I don't have information required to make the image optimally
> compressible.
> At best I could simulate LZW compression in swscale just for the purpose of
> remapping/dithering filter, and then expect the GIF codec to LZW-compress
> the remapped image again. However, that approach doesn't work in practice:
> the second LZW encoder pass ends up making different decisions than the
> first one, falls out of sync with the optimal lossy pattern, and ends up
> creating a large file.
> Given the constraint of true-color input and LZW integrated in one
> algorithm, where's the best place to put that code?

Into GIF encoder.

More information about the ffmpeg-devel mailing list