New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 239
Closed: Mar 2016

Sign in to add a comment

Issue 291: libwebp 0.5.0 generates images that libwebp 0.4.2 corrupts while decoding

Reported by, Mar 15 2016

Issue description

What steps will reproduce the problem?

1. build libwebp 0.5.0 and 0.4.2
2. Encode the attached or.png with cwebp 0.5.0 with a quality from 97 to 100: /tmp/50/bin/cwebp /tmp/or.png -q 100 -o /tmp/out.webp
3. Decode the resulting webp image with dwebp 0.4.2: /tmp/42/bin/dwebp /tmp/out.webp  -o /tmp/out.png
4. display the png image  
3. Decode the resulting webp image with dwebp 0.4.3, 0.4.4 or 0.5.0 and note that no corruption occurs.

This issue has also been observed on various Samsung devices running Android 5.1.1 and the builtin "Internet" Samsung/3.2 browser, based on chromium 32955220, such as a Galaxy S6, Galaxy S5 mini and Note 4.

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

0.5.0 and 0.4.2 on RHEL 7, OpenSuSE 13 and Ubuntu 15.10 with the native gcc versions (4.8 and 5.2.1)

The attached or.png is a crop of the upper left corner of the original image, but displays/causes the same kind of corruption as the original. The original is corrupted from roughly the same starting position all the way to the right and the bottom.
11.7 KB View Download
14.4 KB View Download

Comment 1 by, Mar 15 2016

Project Member
Thanks for the report! This seems related to the following fix for  bug #239 , that was present in 0.4.2:

(it was reported here

Will be verifying.

Comment 2 by, Mar 15 2016

Project Member
Mergedinto: 239
Status: Duplicate (was: New)
I can confirm: applying patch #73580 on top of pristine 0.4.2 source tree fixes the decoding bug.

I fear the problematic devices will need a patching with #73580, or an update if possible.

(for tracking purpose, i attach the problematic webp file generated by 0.5.0 here: or.webp)
5.7 KB Download

Comment 3 by, Mar 15 2016

Sadly, we generate those images on the fly, and we don't check them individually, and the devices in question aren't ours.

Are you saying that "or.webp" is a valid webp image and it is solely the decoder's fault that it is not displayed correctly?

Do you have any idea if any settings during encoding that would guarantee that libwebp 0.5.0 does not generate images older clients don't understand? E.g. is there any specific difference between q=96 and q>=97 that would be necessary for this problem to occur?

Comment 4 by, Mar 15 2016

Project Member
There's no safe way of working around the bug with encoding parameters. That's why the feature was disabled at code level with this patch as soon as the bug was discovered.
This protection was only in HEAD at this time, and was subsequently removed with patch in prevision of the 0.5.0 release.
Apparently, this was somehow premature since there's still some 0.4.2 devices out in the wild.

Note that this decoding bug was present in releases 0.4.0 and 0.4.1 too (but not 0.3.1).

So for short: version 0.4.0 -> 0.4.3 have the decoding bug. All HEAD revisions between 0.4.3 and 0.5.0 (exclusive) didn't have the encoding bug. But 0.5.0 and up can still generate bitstreams non decodable by 0.4.0->0.4.3.

Best is probably for you to re-apply patch #73607 on top on your 0.5.0 tree to re-disable the encoding bug.

Comment 5 by, Mar 15 2016

> Apparently, this was somehow premature since there's still some 0.4.2 devices out in the wild.

For what it's worth, Chrome doesn't make any problems, and Samsung marks newer versions of "SamsungBrowser" as incompatible with hardware that was released less than a year ago.

If my quick test was accurate, patch #73607 on top of 0.5.0 indeed fixes this problem for us.

Will future releases of libwebp remain incompatible with 0.4.2?

Comment 6 by, Mar 16 2016

Project Member
yes, i think the reasonable step here is to re-instate the encoder-fix patch in HEAD (for releases 0.5.x > 0.5.0), considering that they are still a sizable amount of 0.4.x-based devices out there.

 Will update this bug when the patch is in...

Comment 7 by, Mar 25 2016

Project Member
encoder fix has been submitted as per commit 97934e2
we'll have to wait a bit longer for 0.4.x to age out before removing it (again).
Thanks for the report!

Comment 8 by, May 31 2016

Project Member
 Issue 298  has been merged into this issue.

Sign in to add a comment