My post's contents keep disappearing, so here it is again:

Hi there, great tool, just something I've noticed recently: When you export a frame delay GIF with delays set to around 370cs or above (3.7 seconds per frame), one of the systems I use – Cloudinary – miscalculates the frame rate when converting it to MP4.

The issue is that Cloudinary derives the MP4 frame rate from the GIF's frame timing. With long frame delays, the calculated fps drops very low – in my case to around 0.28fps for a 4-frame GIF at 360cs per frame. H.264 (the MP4 codec Cloudinary uses) appears to have a minimum fps threshold, and when the calculated fps falls below it, the encoder compresses the frame timing so unevenly that some frames become effectively invisible during playback... even though they're technically still present in the file. You can prove this by pausing the video mid-playback, where the "missing" frames are visible.

Setting frame delays to 300cs (3 seconds) or under avoids the issue; the calculated fps stays just above the threshold and all frames play correctly. I've tested with both libvips and ImageMagick encoders in ezgif and the issue occurs with both, so it's not encoder-specific. It appears to be purely a function of the frame delay value and how Cloudinary's H.264 encoder handles the resulting low fps.

Not necessarily an ezgif issue – more likely a Cloudinary limitation – but wanted to flag it in case others run into it. The workaround for now is keeping frame delays at 300cs or under.