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).
Signed-off-by: William Storey <will at summercat.com>
In the past I've noticed that situation myself, as well, so I decided to
take a few minutes to look into the issue today.
Your change seems to work for the current state of the gif loader plugin
in the current versions of GIMP, which made me figure that perhaps this
(s->mode == FF_LZW_GIF) logic is no longer needed.
So I decided to look around at the GIMP code base, where I found the
following commit that seemed related to this:
https://github.com/GNOME/gimp/commit/f86655bb1fcf356524c1894096f4866633cc7666
The plugin code itself is a bit of heavy reading, so I could be
mistaken,
but the impression I get from examining this code suggests that older
packages using pre-2013 versions of GIMP were likely affected by this
bug.
I wonder if maybe the ffmpeg commit
b4e2e03709996a0836f6a71535d48b50201338eb
was needed back then, possibly for users who had not yet upgraded to
newer
versions of GIMP packages. So from that point of view, it made sense to
continue to perform that check, at least until that particular GIMP had
become more mainstreamed.
Now, given that GIMP no longer contains that out-of-input-bits
condition,
and hasn't for a number of years, I think revisiting the arguments for
keeping this might be warranted.
Alternatively, if anyone knows any other application that behaves in a
manner requiring this code, or if there is some obscure-but-essential
reason, I suppose we could keep it. At this time, however, it appears
to me that only GIMP might have actually needed it.
-Robert Bisewski
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
