Issue 535 in webp: Losslessly compressing the attached PNG produces a broken file

7 views
Skip to first unread message

sand… via monorail

unread,
Aug 5, 2021, 3:19:23 AMAug 5
to webp-d...@webmproject.org
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 535 by sand...@gmail.com: Losslessly compressing the attached PNG produces a broken file
https://bugs.chromium.org/p/webp/issues/detail?id=535

What steps will reproduce the problem?
1. Compress attached cut_x_lef.png with `cwebp -z 9 cut_x_lef.png -o cut_x_lef.webp`

What is the expected output? What do you see instead?

Expected output is a valid lossless WebP image.
Instead, the resulting image uses the color indexing transform twice. This is not allowed per the specification: "Each transform is allowed to be used only once."
I have attached the resulting image I get.

What version of the product are you using? On what operating system?

Version 1.2.0. I also tested latest git as of commit c5bc3624 and the issue also occurs with it.
Operating system is Windows 10 21H1.

Please provide any additional information below.

I noticed the issue because FFmpeg's lossless WebP decoder validates that transforms
are only used once and rejects images which use the same transform multiple times:
https://github.com/FFmpeg/FFmpeg/blob/82123e133db6d556f3366a1cbb4f0439d70539d4/libavcodec/webp.c#L1130-L1135

Attachments:
cut_x_lef.png 18.1 KB
cut_x_lef.webp 194 bytes

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

mar… via monorail

unread,
Aug 6, 2021, 11:51:46 AMAug 6
to webp-d...@webmproject.org
Updates:
Status: Accepted

Comment #1 on issue 535 by mar...@google.com: Losslessly compressing the attached PNG produces a broken file
https://bugs.chromium.org/p/webp/issues/detail?id=535#c1

Thank you for the report. This is actually a bug in ffmpeg. The libwebp decoder also rejects images where the same transform appears multiple time, so the file would not show in Chrome if that happened. https://chromium.googlesource.com/webm/libwebp/+/1.0.0/src/dec/vp8l_dec.c#1255

This webp image only contains two transforms: a color indexing transform (which triggers "pixel packing" since there are only 2 colors), followed by a predictor transform.

Ffmpeg has a bug in the code reading the predictor transform data, which causes the rest of the decoding to fail (in this case by erroneously reading more transforms).
The bug is triggered when a predictor or color transform follows a color indexing transform with 16 or fewer colors (which causes pixel packing).

One way to fix it (not sure if it's the best way) would be to change this line: https://github.com/FFmpeg/FFmpeg/blob/82123e133db6d556f3366a1cbb4f0439d70539d4/libavcodec/webp.c#L463 to something like:
PARSE_BLOCK_SIZE(s->reduced_width > 0 ? s->reduced_width : s->width, s->height);

We'll follow up with the ffmpeg developers.

sand… via monorail

unread,
Aug 7, 2021, 3:40:12 AMAug 7
to webp-d...@webmproject.org

Comment #2 on issue 535 by sand...@gmail.com: Losslessly compressing the attached PNG produces a broken file
https://bugs.chromium.org/p/webp/issues/detail?id=535#c2

Thanks for the analysis, and apologies for blaming the WebP encoder here. FFmpeg's code looked reasonable when a debugged it and hence I assumed the image used the transform twice like FFmpeg code thought.

mar… via monorail

unread,
Aug 9, 2021, 8:47:49 AMAug 9
to webp-d...@webmproject.org

Comment #3 on issue 535 by mar...@google.com: Losslessly compressing the attached PNG produces a broken file
https://bugs.chromium.org/p/webp/issues/detail?id=535#c3

No problem, thank you for flagging. I've filed https://trac.ffmpeg.org/ticket/9368 using your image.

jz… via monorail

unread,
Aug 12, 2021, 9:20:24 PMAug 12
to webp-d...@webmproject.org
Updates:
Status: Invalid

Comment #4 on issue 535 by jz...@google.com: Losslessly compressing the attached PNG produces a broken file
https://bugs.chromium.org/p/webp/issues/detail?id=535#c4

I'll close this since the issue appears to be with ffmpeg. The file decodes successfully with dwebp.
Reply all
Reply to author
Forward
0 new messages