Unable to decode an image with 0.4.1 that worked with 0.4

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run dwebp.exe zelda.webp -o zelda.png
2.
3.

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

Expected zelda.png. Got Status: 7(NOT_ENOUGH_DATA) error.

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

dwebp 0.4.1 on Windows XP

Please provide any additional information below.

Image worked fine on dwebp 0.4

Original issue reported on code.google.com by file.xtr...@gmail.com on 14 Sep 2014 at 4:02

Attachments:

• zelda.webp

[GoogleCodeExporter]

Thanks for the report. It seems the file is missing a padding byte at the end.
Hence, the ParseRIFF() function fails the verification at line webp.c:81

if (have_all_data && (size > *data_size - CHUNK_HEADER_SIZE)) {
        return VP8_STATUS_NOT_ENOUGH_DATA;  // Truncated bitstream.
}

because: size = 17468 and data_size = 17475 (and CHUNK_HEADER_SIZE = 8).

Attached, is a 'fixed' file with an extra 0 padding byte added at the end, for 
definiteness.

The related commit is 
https://code.google.com/p/webm/source/detail?repo=libwebp&r=1684f4ee375db5ca3fd6
c3388e743833faa4f063
This patch made the decoder checks stricter, in response of the bug report 
#185: 

 https://code.google.com/p/webp/issues/detail?id=185

How was the original file encoded?

Original comment by pascal.m...@gmail.com on 14 Sep 2014 at 7:21

Attachments:

• zelda_padded.webp

[GoogleCodeExporter]

closing the bug. Explanation on the mailing list was:

"This was a test image that was created with a very early version of libwebp, 
the timestamp on the file is 2011-02-17. It was the only one I found that 
failed decoding."

Original comment by pascal.m...@gmail.com on 14 Sep 2014 at 9:00

• Changed state: Done