Closed eslerm closed 1 year ago
This also happens with other GIFs, for example where the last frame has a longer delay to pause between loops.
I assume this happens because the video format uses timecodes rather than frame durations, so an additional time code (or frame?) has to be inserted at the end to cap off the video.
Here's a side-by-side comparison: https://tiggi.es/@Qazm/109943381587454989 The first file was uploaded as WebM (including a duplicate after the pause frame) while the one on the right was a looping GIF with long final frame.
(v4.1.0)
FWIW this bug is fixed in the next version of ffmpeg (current version is 6.0).
Thank you @c960657
Closing since servers which want this resolved can use a version of ffmpeg patched with http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=ff72256235aeaa2a4e197b54f69bad36d61a57d0
Steps to reproduce the problem
Expected behavior
The delay on each frame is equal.
Actual behavior
The first frame correctly delays. The second frame only displays for a split second.
Specifications
v3.5.1 (mastodon.social)
Here is an example gif which does not work: http://polyducks.co.uk/what-is-textmode/anatomy.gif
With gimp I can duplicate all frames (4 total) and then Mastodon is able to convert the new gif to mp4 with proper delays.