[GH-ISSUE #1068] FFmpeg importer drops any frames with unchanged pixels into the editor

kerem commented

2026-02-26 09:32:42 +03:00

Owner

Originally created by @ParticleCore on GitHub (Feb 3, 2022).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1068

Originally assigned to: @NickeManarin on GitHub.

Describe the bug
When importing an mp4 using the ffmpeg importer any unchanged frames are automatically dropped and there is no option to disable that behavior.
When importing the same video using the mediaplayer importer, all frames are imported correctly, but the frame rate becomes really choppy/not as smooth as when importing with ffmpeg.

Note: I am not referring to when we save the video as a gif, but when we import it into the editor. Right away I can tell there are missing frames when I hit play in the editor.

To Reproduce
Steps to reproduce the behavior:

A good video sample to test this with is a 30s recording of your desktop where nothing at all changes. When importing using the ffmpeg only 1 frame shows in the editor.

Open editor
With the ffmpeg import an mp4 that has at least one period where no pixels change at all
Press play in the editor
The period with no pixels changed is gone
Repeat the same process above but use the mediaplayer importer
The period with no pixels changed is present, but the framerate is really bad

Expected behavior
The importer should not be dropping frames arbitrarily

Desktop (please complete the following information):

OS: Windows 10
Version 10.0.19042 Build 19042
ScreenToGif 2.35.4

Comments
I don't know if the ffmpeg issue is normal and its the editor that is not adding the correct time to the frames that should represent the period where nothing changes in the video, and instead is putting the same short duration for all frames making it look like the unchanged pixels periods are missing. I mention this because that is what makes sense to me, the period with no pixels change at all should be represented by a single frame with a duration of that period.

Originally created by @ParticleCore on GitHub (Feb 3, 2022). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1068 Originally assigned to: @NickeManarin on GitHub. **Describe the bug** When importing an mp4 using the ffmpeg importer any unchanged frames are automatically dropped and there is no option to disable that behavior. When importing the same video using the mediaplayer importer, all frames are imported correctly, but the frame rate becomes really choppy/not as smooth as when importing with ffmpeg. Note: I am not referring to when we save the video as a gif, but when we import it into the editor. Right away I can tell there are missing frames when I hit play in the editor. **To Reproduce** Steps to reproduce the behavior: A good video sample to test this with is a 30s recording of your desktop where nothing at all changes. When importing using the ffmpeg only 1 frame shows in the editor. Open editor With the ffmpeg import an mp4 that has at least one period where no pixels change at all Press play in the editor The period with no pixels changed is gone Repeat the same process above but use the mediaplayer importer The period with no pixels changed is present, but the framerate is really bad **Expected behavior** The importer should not be dropping frames arbitrarily **Desktop (please complete the following information):** - OS: Windows 10 - Version 10.0.19042 Build 19042 - ScreenToGif 2.35.4 **Comments** I don't know if the ffmpeg issue is normal and its the editor that is not adding the correct time to the frames that should represent the period where nothing changes in the video, and instead is putting the same short duration for all frames making it look like the unchanged pixels periods are missing. I mention this because that is what makes sense to me, the period with no pixels change at all should be represented by a single frame with a duration of that period.

kerem added the

🔷 Bug 🐛

⬜ Pending

labels

2026-02-26 09:32:42 +03:00

kerem commented

2026-02-26 09:32:42 +03:00

Author

Owner

@NickeManarin commented on GitHub (May 1, 2022):

Hi, do you have a sample video so that I could test?

@NickeManarin commented on GitHub (May 1, 2022): Hi, do you have a sample video so that I could test?

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (May 2, 2022):

I am not sure what is going on now, but the issue I reported originally appears to have changed to a different issue where the gif produced using FFmpeg is being slowed down even though I did not configure it to be slowed down.

When I imported the video I used these settings:

And these are the settings I used for exporting the gif:

This is the resulting GIF, it's apparently playing at half the speed despite not having configured it to do such thing: https://file.io/n6HCwU12XfNQ

This is the original video I used for this example: https://file.io/cdstlV1ZSazc

I had to upload them off site because they were bigger than the GitHub 10MB limit.

@ParticleCore commented on GitHub (May 2, 2022): I am not sure what is going on now, but the issue I reported originally appears to have changed to a different issue where the gif produced using FFmpeg is being slowed down even though I did not configure it to be slowed down. When I imported the video I used these settings: ![image](https://user-images.githubusercontent.com/9222661/166264498-02465d09-3827-4657-ac2a-67b7dd59f2f6.png) And these are the settings I used for exporting the gif: ![image](https://user-images.githubusercontent.com/9222661/166264374-5860a8ac-1cb3-488c-bb51-8ba5ea3a5451.png) This is the resulting GIF, it's apparently playing at half the speed despite not having configured it to do such thing: https://file.io/n6HCwU12XfNQ This is the original video I used for this example: https://file.io/cdstlV1ZSazc I had to upload them off site because they were bigger than the GitHub 10MB limit.

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (May 2, 2022):

By the way that was done using v2.37

@ParticleCore commented on GitHub (May 2, 2022): By the way that was done using v2.37

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (May 24, 2022):

Seems like this new version basically ignores the frame times when exporting. I've tried multiple recordings and even reduced the time for all frames to the min possible (10ms) and after saving the gif it plays very slow, like 30ms per frame or so. I don't understand what is going on right now, and I tried different decoders.

@ParticleCore commented on GitHub (May 24, 2022): Seems like this new version basically ignores the frame times when exporting. I've tried multiple recordings and even reduced the time for all frames to the min possible (10ms) and after saving the gif it plays very slow, like 30ms per frame or so. I don't understand what is going on right now, and I tried different decoders.

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (May 24, 2022):

I was able to find the settings for the app and deleted them entirely after uninstalling the app and switched to the portable version, it is working correctly now. I do not understand what was happening in the settings before, but something was causing my problems there somehow.

@ParticleCore commented on GitHub (May 24, 2022): I was able to find the settings for the app and deleted them entirely after uninstalling the app and switched to the portable version, it is working correctly now. I do not understand what was happening in the settings before, but something was causing my problems there somehow.

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (May 24, 2022):

I was able to recover the deleted settings in case it might be useful to find why this issue was happening to me
Settings - Copy.txt

@ParticleCore commented on GitHub (May 24, 2022): I was able to recover the deleted settings in case it might be useful to find why this issue was happening to me [Settings - Copy.txt](https://github.com/NickeManarin/ScreenToGif/files/8763871/Settings.-.Copy.txt)

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (May 24, 2022):

I believe the issue is with frame rates higher than 30fps. If I record using screentogif with the frame rate set to 60 then the slowness output occurs. It feels like when it is saving the recording into gif it is doubling the times based on the 60fps, instead of adjusting for that in the frames themselves, their own individual timings.

As a temporary workaround for this problem I have enabled "Fixed frame rate" in the recording settings, and now I am able to record and export in 60fps without the slowness problem.

@ParticleCore commented on GitHub (May 24, 2022): I believe the issue is with frame rates higher than 30fps. If I record using screentogif with the frame rate set to 60 then the slowness output occurs. It feels like when it is saving the recording into gif it is doubling the times based on the 60fps, instead of adjusting for that in the frames themselves, their own individual timings. As a temporary workaround for this problem I have enabled "Fixed frame rate" in the recording settings, and now I am able to record and export in 60fps without the slowness problem.

kerem commented

2026-02-26 09:32:43 +03:00

Author

Owner

@ParticleCore commented on GitHub (Aug 27, 2024):

Original issue is still present in 2.41

@ParticleCore commented on GitHub (Aug 27, 2024): Original issue is still present in 2.41

kerem referenced this issue

2026-02-26 09:34:03 +03:00

[PR #805] [MERGED] Bugfix: KeyList was cleared too late #1215

Rows
Columns

[GH-ISSUE #1068] FFmpeg importer drops any frames with unchanged pixels into the editor #805