Closed GoogleCodeExporter closed 9 years ago
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
> 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
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:
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
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
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
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
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
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
Original comment by urv...@google.com
on 11 Feb 2014 at 2:24
Original issue reported on code.google.com by
jz...@google.com
on 26 Mar 2013 at 6:28