gif2webp converted image displays at a greater rate than the original

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download http://en.wikipedia.org/wiki/File:Black_hole_lensing_web.gif 
2. convert using gif2webp
3. display with vwebp

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

The rates should match, but this gif plays faster in some applications: 
ImageMagick/animate 6.6.9-7, gifview 1.64, mplayer@r35934 
(ffmpeg@N-50607-g22cc8a1) and vwebp with the converted webp, than others: 
Chrome M26, Opera 12.14, FireFox 19.02, ffplay@N-51205-gac9b056.

Original mailing list text:

Some animated Gifs I found are quite strange in delay times, as an example: 
http://en.wikipedia.org/wiki/File:Black_hole_lensing_web.gif

Many Browsers seems to play it realy slow, but if you view the converted webP 
it is too fast.

May be an option in gif2web to multiply the delay times (or using a more 
complex function) could help.

Original issue reported on code.google.com by jz...@google.com on 26 Mar 2013 at 6:28

[GoogleCodeExporter]

Is this really an error?

It seems more like the browsers protect themselves from potentially too fast 
(too resource intensive) GIFs and choose to ignore very short frame delays. The 
image in question has a frame delay of 10ms and Firefox probably does not want 
to play it at 100 fps. I do not see a real problem in any of the tools.

Original comment by vlastimi...@gmail.com on 26 Mar 2013 at 7:25

[GoogleCodeExporter]

> Is this really an error?
> 
> [...]

Thanks for the update. I didn't look at the contents of the file, I was just 
noting we should determine the cause of the difference.

Original comment by jz...@google.com on 26 Mar 2013 at 7:32

[GoogleCodeExporter]

We made a gif to webm converter for memecenter and there were many gifs having 
frames with 0cs duration. To come up with a similar effect as "animated gif" we 
used this adjustment:

//these values are as centiseconds
if(frameduration == 0) frameduration = 10;
else if(frameduration < 3) frameduration = 3;

Original comment by ufukalti...@gmail.com on 26 Mar 2013 at 8:27

Attachments:

• gif2webp.diff

[GoogleCodeExporter]

Humm, not sure if users will always want gif2webp tool to fix these delays.
How about a command-line option (say -fix_delays), so that delays would be 
fixed only if users explicitly ask for it?

Original comment by urv...@google.com on 29 Mar 2013 at 2:38

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yes giving that option to users would be great. However I think on %99.9 case 
people will use -fix_delays. Because the usual case would be converting 
existing gifs and there are many gifs out there with sketchy framerates.

Original comment by ufukalti...@gmail.com on 8 Apr 2013 at 7:58

[GoogleCodeExporter]

Humm, so I was looking at what the exact behavior of 'fix_delays' be, and came 
across this article:
http://humpy77.deviantart.com/journal/Frame-Delay-Times-for-Animated-GIFs-240992
090

Looks like different browsers interpret delays < 10ms differently. But, the 
common denominator is that all of them consider < 3ms delays to be invalid and 
interprete them as 3ms or 10ms instead. And that seems to make sense, 
considering that the refresh rate of most screens is <= 90Hz.

So, I'd say the fix should be this:
if(frameduration < 3) frameduration = 3;

Original comment by urv...@google.com on 11 Apr 2013 at 9:52

[GoogleCodeExporter]

actually, i think the bunch of frames with too-short duration should be _fused_ 
together, and not dropped or capped in duration.

Original comment by pascal.m...@gmail.com on 19 Apr 2013 at 7:22

[GoogleCodeExporter]

You will not get a similar behaviour as browsers if you fuse frames.

Original comment by ufukalti...@gmail.com on 19 Apr 2013 at 10:14

[GoogleCodeExporter]

Looking at how different browsers show such images a bit differently, I feel 
the best way to go is to keep the same durations as the original in the 
bitstream, and let the browsers decide how they want to interpret them (just 
like what they do for GIF).

Original comment by urv...@google.com on 26 Dec 2013 at 9:36

[GoogleCodeExporter]

Original comment by urv...@google.com on 11 Feb 2014 at 2:24

• Changed state: Invalid