[FFmpeg-devel] [PATCH] Animated GIF Support

Don Moir donmoir at comcast.net
Sat Oct 13 18:45:58 CEST 2012

> On 10/12/12, Vitaliy Sugrobov <vsugrob at hotmail.com> wrote:
>>> How will this work with seeking?
>>> This means that first frame is keyframe and any other frame with
>>> transparency is not.> I think that right place to handle this is not in
>>> decoder but from user.
>>> AFAIK mplayer should handle it and ffplay not.
>> According to gif spec any
>> subsequent frame depends on all previous frames. And this is not only
>> because of transparency, the other reason is variable frame dimensions. In
>> more detail: gif header provides us initial image dimensions { width,
>> height }. Then, any subsequent frame specifies its { x, y, width, height }
>> characteristics within bounds of the canvas, which means than only portion
>> of the canvas is updated. Thus first frame might be considered as a
>> keyframe and any other frame with or without transparency is not a
>> keyframe. So there is no way to seek frame F without calculating preceding
>> frames A, B, C, D and E.
> Then mark packets/frames as such in demuxer/decoder.

You could mark keyframes based on the disposal method and size but requires reading thru the file to find out what the size and 
disposal method is for various frames. 

More information about the ffmpeg-devel mailing list