Issue 379 in webp: huge different frame rate with origin GIF image

[huanghua… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 379 by huanghua...@gmail.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379

What steps will reproduce the problem?
0. wget https://a.appsimg.com/upload/flow/2018/03/06/34/15202980891368.gif -O test.gif
1. gif2webp -q 75 -metadata none -mt -quiet -lossy test.gif -o test.webp
2. open test.gif test.webp with chrome browser then we can see the frame rate to show with huge difference

I think the frame rate should be same.

This occurs at libwebp-0.6.0 on CentOS 7.2
giflib under version 4.1.6-9

md5sum test.gif
27dde0fcc226d1dde509b831f8ab4561 test.gif



--
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

[huanghua… via monorail]

Comment #1 on issue 379 by huanghua...@gmail.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c1

(No comment was entered for this change.)

Attachments:
test.gif 50.5 KB

[jz… via monorail]

Comment #2 on issue 379 by jz...@google.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c2

The gif file has frames with 0 delay which chrome will force to be 100ms [1]. gif2webp copies this and webp has been treated the same [2], but here we might be losing some of the empty filler frames. The source has 9 frames with resolution > 1x1; the other 25 are filler with 0 duration.

As a workaround webpmux could be used to set the duration for the remaining frames.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/DeferredImageDecoder.cpp?rcl=b4c33049f096cd283f32be9a58b9a9e768227c26&l=246
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=454693

[huanghua… via monorail]

Comment #4 on issue 379 by huanghua...@gmail.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c4

when update frame timestamp, process the frame_duration, it seems to work.

https://github.com/webmproject/libwebp/blob/master/examples/gif2webp.c#L364
// Update timestamp (for next frame).
if (frame_duration <= 10) {
frame_duration = 100;
}
frame_timestamp += frame_duration;

[jz… via monorail]

Comment #5 on issue 379 by jz...@google.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c5

That's an option, though it locks us to some renderer implementations. This could also be special cased to prevent frame dropping while still retaining the original duration values.

[pascal.m… via monorail]

Comment #6 on issue 379 by pascal.m...@gmail.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c6

So, if i understand the problem correctly, it's unfortunate that the encoded WebP file ends up with *all* frames having duration 0. This should be prevented.

As for matching the expected GIF behaviour, well it indeed tie us to Chrome / Firefox's behaviour if we make frames with duration <= 10ms be forced to 100ms. But a lot of ads and other GIFs out there actually rely on this behaviour.
So, few options:
* have a -gif-compat flag
* or say that if more than 2 (or N) successive frames have a 0-duration, they are actually expected to be fillers and we force 100ms for each.

* ... any other option?

[jz… via monorail]

Comment #7 on issue 379 by jz...@google.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c7

> So, few options:
> * have a -gif-compat flag
> * or say that if more than 2 (or N) successive frames have a 0-duration, they are actually expected to be fillers and we force 100ms for each.

close to the 2nd, we could just faithfully reproduce the 0ms frames with a transparent 1x1 frame (34 bytes lossless) instead of dropping the frame.

[jz… via monorail]

Updates:
Owner: jz...@google.com

Comment #8 on issue 379 by jz...@google.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c8

Actually in looking at the behavior in various transcoding tools and the known behavior in web browsers the change mentioned in comment #4 makes sense.

[pascal.m… via monorail]

Comment #9 on issue 379 by pascal.m...@gmail.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c9

sounds like a good solution. All the more that it doesn't imply changing the core library, but just the gif2webp tool.

[bugdro… via monorail]

Comment #10 on issue 379 by bugd...@chromium.org: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c10

The following revision refers to this bug:
https://chromium.googlesource.com/webm/libwebp/+/09333097ed4fd474916edf723d1ad07f72a9ab4d

commit 09333097ed4fd474916edf723d1ad07f72a9ab4d
Author: James Zern <jz...@google.com>
Date: Sat Mar 24 07:26:53 2018

gif2webp: force low duration frames to 100ms

this is consistent with web browser behavior as well as various
transcoding tools (ffmpeg, gif2apng, etc).

also: update anim_diff to account for this new behaviour.

BUG=webp:379

Change-Id: I70cc72a6b401ef32b73cd182a3f12d993d495bf4

[modify] https://crrev.com/09333097ed4fd474916edf723d1ad07f72a9ab4d/examples/gif2webp.c
[modify] https://crrev.com/09333097ed4fd474916edf723d1ad07f72a9ab4d/examples/anim_util.c

[jz… via monorail]

Updates:
Labels: v0.6.2
Status: Fixed

Comment #11 on issue 379 by jz...@google.com: huge different frame rate with origin GIF image
https://bugs.chromium.org/p/webp/issues/detail?id=379#c11

Thanks for the report, this should be fixed in the master branch now and will be included in the next release.