Why does FFmpeg choose 10+20+20 ms instead of an even 16 ms for 60 fps GIF images

animated gifffmpegvideo

I have a short 60 fps video which I'd like to turn into a GIF file. I run

ffmpeg -i foo.flv foo.gif

and it produces a GIF file. Great!

The only problem is that the motion in the produced GIF video is janky and uneven. If I use another tool, I can see that FFmpeg has created a video where the first frame is 10 ms long, the second 20 ms, the third 20 ms, and then it repeats like that: 10 ms, 20 ms, 20 ms. If I use another tool to smooth it out to an even 16 ms for each frame (without changing the frame contents), the result looks beautiful.

Why is FFmpeg doing this? How can I ask it to write a GIF file that requests an even 16 ms per frame instead, so that I don't need to use a second tool?

I have now seen this related question asking whether 60 fps GIF videos even exist, but it doesn't address the question of how to ask FFmpeg to change its behavior. Additionally, it raises a new question: if 16ms is not a time that GIF can represent, what is the other tool I'm using doing, and why does it work well?

Best Answer

As discussed at Do 60 FPS GIF's actually exist? Or is the maximum 50 FPS?, the resolution of frame times in GIF is 10ms, so a nice even 16ms per frame is not possible. So the answers to the questions, in order, are:

Why is ffmpeg doing this?

Because 10+20+20 gets you 60fps on average, and is the most precise approximation with that property that can be represented within the constraints of the GIF format.

How can I ask it to write a gif that requests an even 16ms per frame instead, so that I don't need to use a second tool?

You can't, because the gif format can't represent that. But I've found that asking it to make a 50fps video -- which can be exactly represented in the GIF format -- produces nice smooth results. This can be done with:

ffmpeg -i foo.flv -vf fps=50 foo.gif

This uses nearest-neighbor temporal interpolation to choose which frame to transfer to the output.

If 16ms is not a time that gif can represent, what is the other tool I'm using doing, and why does it work well?

The other tool I was using was GIMP, and its choice is to round each frame to the nearest representable size, so it was silently changing my requested 16ms/frame to 20ms/frame. It probably works well because my poor human eyes can't tell that everything was happening just slightly too slowly to be correct; only that motions were happening smoothly instead of at unusually-spaced intervals.

Related Solutions

FFmpeg – Reduce Video Frame Rate Without Dropping Useful Frames

I managed to fix my file. I found the mpdecimate filter, which drops duplicate or near duplicate frames from a video stream. First I tried:

ffmpeg -loglevel debug -i orig.mp4 -an -vf "mpdecimate" test.mp4

I added -loglevel debug to get more info during transcoding. The info showed what mpdecimate was doing with the frames, which was lots and lots of this pattern:

lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:44032 pts_time:3.44 drop_count:1
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:44544 pts_time:3.48 drop_count:2
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:45056 pts_time:3.52 drop_count:3
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:45568 pts_time:3.56 drop_count:4
781>=hi keep pts:46080 pts_time:3.6 drop_count:-1
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:46592 pts_time:3.64 drop_count:1
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:47104 pts_time:3.68 drop_count:2
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:47616 pts_time:3.72 drop_count:3
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:48128 pts_time:3.76 drop_count:4
821>=hi keep pts:48640 pts_time:3.8 drop_count:-1
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:49152 pts_time:3.84 drop_count:1
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:49664 pts_time:3.88 drop_count:2
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:50176 pts_time:3.92 drop_count:3
lo:0<217 lo:0<-2147483648 lo:0<-2147483648 drop pts:50688 pts_time:3.96 drop_count:4
793>=hi keep pts:51200 pts_time:4 drop_count:-1

I.e., it was consistently dropping 4 frames in a row as duplicates and keeping every 5th. This showed that the original frame rate was 1/5th of what it was now. I was lucky! Since the video's current 25 fps was a multiple of the original frame rate, there shouldn't be a problem with temporal misalignment of the kept and dropped frames. Therefore I retranscoded the original video with nothing more complex than -vf "fps=5", and the output seemed to be fine. Just to be sure, I piped the output through the mpdecimate filter, and it detected all remaining frames as a "keep". So the original file was not so messed up as I thought.

Extracting frame timestamp (PTS) and seting it as a file name

ffmpeg docs suggests this to timestamp ALL frames- ffmpeg -i input.mp4 -f image2 -frame_pts true %d.jpg

If you check out https://ffmpeg.org/ffmpeg-all.html and search for "expand the filename with pts"

but I dont think its the true Presentation Time Stamp, rather its an index.

Best Answer

Related Solutions

FFmpeg – Reduce Video Frame Rate Without Dropping Useful Frames

Extracting frame timestamp (PTS) and seting it as a file name

Related Question