[FFmpeg-devel] [PATCH] Animated GIF Support

[Michael Niedermayer]

On Thu, Oct 18, 2012 at 09:19:44AM +0400, Vitaliy Sugrobov wrote:
> On 10/14/12, Clément Bœsch <ubitux at gmail.com> wrote:
> > BTW, are you going to work on the encode? There is room for improvement
> > there; I think it is intra-only at the moment (because the output gif are
> > pretty huge). Also, you need some tricks to get a nice gif output (like
> > doing things such as -vf ...,format=rgb8,format=rgb24 to get better
> > colors).
> 
> Rather no than yes. Gif encoding is a story about dithering and optimal
> color reduction strategies.. I'm not good in that.
> 
> > Anyway, following is a small review of your code, with a lot of style &
> > nit stuff, sorry :)
> 
> Thank you for such detailed review:) I've fixed those little defects
> regarding to style, comments, const pointers, vertical align and type
> casts.
> 
> > > +/**
> > > + * GIF format allows variable delay between frames without having
> > > + * any notion of "frames per second". But since frames decoded with ffmpeg demuxer,
> > > + * we have to adhere requirement of some fixed fps.
> > > + */
> > > +#define GIF_DEFAULT_RATE    25
> > > +/**
> > > + * Major web browsers display gifs at ~10-15fps when rate
> > > + * is not explicitly set or have too low values. We assume default rate to be 10.
> > > + * Default delay = 100hundredths of second / 10fps = 10hos per frame.
> > > + */
> > > +#define GIF_DEFAULT_DELAY   10
> > 
> > It really plays it faster in Firefox and Chromium for me: I'm trying with
> > the following generated gif, and ffplay has a way slower playback:
> > 
> > ./ffmpeg -i ~/samples/big_buck_bunny_1080p_h264.mov -ss 45 -vf \
> >         'scale=320:160,format=rgb8,format=rgb24' -r 20  -frames:v 50 -y bbb.gif
> 
> I tried this and got the same result. After some digging I fixed this.
> There were two reasons for that behavior:
> 1) gif encoder produces wrong delay values in output: -r 20 results in
> 0.02 sec delay between frames which is 50 frames per second instead of
> 20! I found that libavformat/gif.c (gif muxer) uses some "jiffies"
> instead of just converting timebase to delay values.
> 2) Firefox and Chromium slow down playback of fast gifs. It seems that
> they set delay between frames to 10 hundredths of second (10fps) when
> they found delay less than 2 (>50fps). I think this is a reasonable
> approach: playing animation at the speed of 100 frames per second would
> be resource consuming task. BTW: Internet Explorer has different delay
> threshold, around 3 hundredths of second.
> 
> In previous version of this patch default threshold was 3, now I changed
> it to 2. Of course, this value can be changed by -gif_min_delay option.
> 
> > > +/**
> > > + * Converts gif time to pts where
> > > + * t is integer time (in hundredths of second) and r is frame rate.
> > > + * Note that result is rounded to the nearest integer.
> > > + */
> > > +#define GIF_TIME_TO_PTS(t,r) ((int)(((t) * (r) / 100.0f) + 0.5f))
> > > +
> > 
> > Can't you just set the timebase correctly and let the FFmpeg internals
> > handle the rescale?
> 
> You're right. Offloaded this task to ffmpeg internals.
> 
> > Overall comment: can't you avoid the image2 demuxer to be selected by
> > default? IIRC a mjpeg stream is similar to this gif thing, and is playable
> > directly;
> > 
> > try ./ffmpeg -f lavfi -i testsrc=d=5 out.mjpeg && ./ffplay out.mjpeg for
> > instance.
> 
> Unfortunately I can't. ff_image2_demuxer has AVFMT_NOFILE flag and its
> read_probe() called even before ffmpeg opened the file. It checks for
> presence of ".gif" extension in the filename and returns some non-zero
> score. FFmpeg satisfied with score greater than zero and do not bother

please look at read_probe() of image2, especially tha special case for
"raw", adding gif there should avoid the problem

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121019/61d7d75d/attachment.asc>