webpmux places frames at wrong position

[GoogleCodeExporter]

What steps will reproduce the problem?

webpmux -frame ./frame_1.webp +80+0+0+0-b -frame ./frame_2.webp +80+5+6+0-b -o 
./ppitsmyluckyday_x5.webp

This will produce a animation with 2 frames. The second frame is a bit smaller 
and is located a few pixels from upper left corner.

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

I expect the second frame to overwrite part of the first frame starting at x 
position 5 and y position 6.
But instead the frame overwrites at x position 4 and y position 6. The second 
frame position is off by a single pixel.

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

Observed using the following version:
libwebp-0.4.0-linux-x86-64.tar.gz
master 790207679d1c5c4e887e386abe4e69977064211b

Please provide any additional information below.

The following two commands should produce different output. (notice the x 
position on second frame for both commands)
webpmux -frame ./frame_1.webp +80+0+0+0-b -frame ./frame_2.webp +80+4+6+0-b -o 
./ppitsmyluckyday_x4.webp
webpmux -frame ./frame_1.webp +80+0+0+0-b -frame ./frame_2.webp +80+5+6+0-b -o 
./ppitsmyluckyday_x5.webp

But the output is binary identical. So this is a format/encoding issue and no 
decoding issue.

Original issue reported on code.google.com by BennyDie...@gmail.com on 16 Jun 2014 at 8:26

Attachments:

• frame_1.webp
• frame_2.webp

[GoogleCodeExporter]

This is the expected behavior, the offsets are stored in the file as 'offset / 
2' [1][2].

[1] https://developers.google.com/speed/webp/docs/riff_container#animation
[2] https://developers.google.com/speed/webp/docs/container-api#webpmuxpushframe

Original comment by jz...@google.com on 17 Jun 2014 at 3:34

• Changed state: Invalid

[GoogleCodeExporter]

Can webpmux print a explanation/error to stderr and return a error code in 
these cases?

Original comment by BennyDie...@gmail.com on 17 Jun 2014 at 9:32

[GoogleCodeExporter]

Good point, a warning might be enough if offsets are programmatically extracted:

https://gerrit.chromium.org/gerrit/#/c/70541/

Original comment by jz...@google.com on 18 Jun 2014 at 6:47