burritojustice, 1 month ago

uploading this to Mastadon was unnecessarily hard!

1500x1500? nope
1280x1280? nope
720x720? sigh

I had also added a slight delay on the first and last frame for the bounce, but this seems to show up as a delay on the second and second-to-last frames which is annoying, testing this GIF again here, maybe a client issue? I’m on Ivory but if you see a weird stutter step on another client let me know

video/mp4

burritojustice, 1 month ago

seeing the stutter step in the mastodon client itself, ugh guess I’m going down a rathole

burritojustice, 1 month ago

while not the same issue this is looking like .gif to .gifv conversion issues with ffmpeg

https://github.com/mastodon/mastodon/issues/5646

jwz, 1 month ago

@burritojustice The delay value associated with a GIF frame is after the frame, but that's not how MPEG timing works. So when converting from GIF to video you have to duplicate frame 0 as frame N with delay 0.

It also doesn't help that GIF measures that delay in 1/100th sec, which cannot represent normal frame rates of 1/30th or 1/60th sec as an integer.

My resize.pl handles this properly: https://www.jwz.org/hacks/#resize

burritojustice, 1 month ago

@jwz thank you — and I so love that you have a script dealing with our common GIF problems

jwz, 1 month ago

@burritojustice My blog converts GIFs to MP4s for display in order to save bandwidth, so I had 20 years of weird GIF test cases that I had to figure out how to make work, since as you have discovered, ffmpeg just throws up its hands.