[FFmpeg-devel] [PATCH] avcodec/lzwenc: Remove padding byte when writing gif

[Will Storey]

> Will Storey will at summercat.com wrote on Mon Feb 20 22:46:34 EET 2017:
> > No longer write a final 0x00 byte when flushing the LZW bitstream. There
> > is no mention of doing this in GIF89a specification to do this, and
> > decoders may not expect it.
> 
> > Adding this byte for padding was added in commit
> > b4e2e03709996a0836f6a71535d48b50201338eb apparently to resolve an issue
> > with GIMP. I could not find any background about this issue. Possibly
> > the GIMP decoder had an issue (it appears to handle gifs without this
> > byte fine today).

Hello, I wanted to inquire whether it will be possible to get this patch
merged in, or if there's anything else I could do to help it along.

I thought it might help if I wrote a bit more about why I made this change
as the commit message is perhaps sparse:

I came across an issue in the Go language's image/gif package where its GIF
decoder failed as it encountered unexpected extra data:
https://github.com/golang/go/issues/16146

I eventually tracked the cause down to there being an extra byte containing
0x00 in a sample GIF. The decoder would complain when the extra byte
occurred as an extra data sub-block inside the GIF.

I fixed this in Go (it now knows to ignore the 1 extra byte), but then I
looked for where such GIFs came from, and that's how I ended up creating
this patch.

The patch removes adding a padding bit of 0. If the encoder filled its last
byte, then adding the padding bit meant adding an extra byte to hold it. If
adding the extra byte happens to be beyond the 255 byte limit in a GIF data
sub-block, then it means adding a new sub-block of size 1, which means the
GIF will contain an extra 2 bytes. (0x01, the size, and 0x00, the content).

Including padding like this is arguably within the GIF 89a specification as
the specification is not very strict in this section. GIF decoders likely
will ignore such extra data. But I think there is no reason to include it.
It is wasteful.

Obviously this is not a huge issue, but it might be nice to adjust.

Thank you for your time. Please let me know if I can provide any more
information or make any changes.