New issue
Advanced search Search tips

Issue 291 link

Starred by 3 users

Issue metadata

Status: Duplicate
Merged: issue 239
Owner:
Closed: Mar 2016



Sign in to add a comment

libwebp 0.5.0 generates images that libwebp 0.4.2 corrupts while decoding

Reported by rainer.c...@sevenval.com, 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 3.2.38.104-0_100601_955220 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.
 
or.png
11.7 KB View Download
out.png
14.4 KB View Download
Project Member

Comment 1 by pascal.m...@gmail.com, Mar 15 2016

Thanks for the report! This seems related to the following fix for  bug #239 , that was present in 0.4.2:
https://chromium-review.googlesource.com/#/c/73580/

(it was reported here https://bugs.chromium.org/p/webp/issues/detail?id=239)

Will be verifying.
Project Member

Comment 2 by pascal.m...@gmail.com, Mar 15 2016

Mergedinto: 239
Owner: pascal.m...@gmail.com
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)
or.webp
5.7 KB Download
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?
Project Member

Comment 4 by pascal.m...@gmail.com, Mar 15 2016

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 https://chromium-review.googlesource.com/#/c/73607/ as soon as the bug was discovered.
This protection was only in HEAD at this time, and was subsequently removed with patch   https://chromium-review.googlesource.com/312552 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. 
> 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?
Project Member

Comment 6 by pascal.m...@gmail.com, Mar 16 2016

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...
Project Member

Comment 7 by pascal.m...@gmail.com, Mar 25 2016

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!
Project Member

Comment 8 by urvang@google.com, May 31 2016

 Issue 298  has been merged into this issue.

Sign in to add a comment