Imported video at 3 fps instead of 30 fps

Hello,

First post here, hello everyone. I have been using Shotcut for almost a year and enjoying it.

I have a problem when importing videos from my smartphone, but only when they come from a timelapse (video mode included in my smartphone app). The imported video has 3 fps instead of 30 fps when imported in Shotcut. The video itself really has 30 fps and plays normally in VLC. After importing, the video has the correct duration but only 3 fps and looks bad (stuttering), as expected. If I import a video from this smartphone but not filmed in timelapse, I get the normal 30 fps (variable framerate detected though). No variable framerate is detected when importing a video with timelapse activated.

This only occured after updating my Shotcut version to 24.11.17. Previously I was using 24.04.28 and this problem did not occur. I tested installing the old version again and the problem was gone.

I am using an Android smartphone, filming at 1080p, 30 fps. Codec is HEVC. OS is Windows 10 64-bit.

Is this a known issue ? I tried looking for something related in the patch notes but could not find a clear answer myself.

No, but it is probably due these documented changes:

  • Improved handling for some variable frame rate videos.
  • Fixed wrong frame rate for Android Camera videos.
  • Fixed 59.94 fps in Matroska falsely identified as variable frame rate.
  • Fixed AVCHD video frame rate is double (could fix other formats).

Shotcut uses the FFmpeg API, which contains a few possible frame rate fields (the subject is more complicated than it may seem). Previously, we used to use our own logic to select from among these. However, finally it settled on using a function from FFmpeg that encapsulates its suggested logic for these fields. Also, during that time frame FFmpeg was upgraded from version 7 to 7.1.

You can try using Properties > Convert on your video to see if that works.

To help better understand the issue in Shotcut choose Properties > menu-button > More Information and look near the end for a line like this:

com.android.capture.fps=

What value does it report? If it contains this line, this is what we use now (see bullet point 2 above). If not, you can copy and paste the info here too.

Thank you for the answer ! The property value of the imported clip is as follows:

com.android.capture.fps=3.000000

However the “Convert” method works, it does not duplicate 1 frame into 10 frames to create a fake 30 fps but it really restored the original frames of the video.

Do you have an idea of some things I could try to fix this issue before / when importing the clips ? This would be easier for me in the future to avoid converting the clips after importing and creating an extra clip for each timelapse.

In any case, thank you for the help, that solved the direct problem. :slight_smile:

Edit but new information : I checked the version of my Camera app on my smartphone and I think it is super outdated…

Could it be the source of the problem, that it saves the metadata of the video in such a way that it does not fit with the current standards and Shotcut interprets it correctly, so with the wrong value ? If this is the case, this is not troubleshooting an issue with Shotcut as I expected but with my app, which I will update promptly if this is confirmed to be the problem !

The FFmpeg function I mentioned does not use this info. So, this is basically our only additional logic on top of it. It was added to address a bug report here. There is nothing you can do to change Shotcut unless you modify the source code of MLT and build it yourself. Instead of transcode you can remux the file so with ffmpeg on the command line so that it no longer has this special metadata. Shotcut includes the ffmpeg executable. Like this

ffmpeg -i PXL_20230108_142208704.mp4 -c copy -map_metadata -1 PXL_20230108_142208704-no-metadata.mp4

This is probably it. If you check properties of that video inside the phone’s gallery does it show the proper fps or just 3?

My phone’s gallery does not allow me to check the video framerate, but Windows properly recognizes 30 fps and plays it accordingly.

I tested several camera apps for my smartphone, but all with the same result (timelapse with speed x10 gave 3 fps but speed x15 gave 7.5 fps, not sure why…).

Anyway ! I would like to avoid building my own version of Shotcut just for this issue so I will use the “Convert” button to restore my timelapses to 30 fps.

Thank you for the help, an happy user.

Oh so all these videos are timelapses? Do regular videos have this same issue?

A 10x video sort-of makes sense to show 3 “real” fps because 3 frames represent 1 second of real time.

The 15x does not make any sense at all.

About half of my content is made of timelapses. The normal speed videos work just fine. I can’t explain the 7.5 fps either…

After playing around the problem today, I now think there is some kind of bug or inconsistency, either only in the Properties displayed or in the way the fps is interpreted under the hood (I think the latter).

If I click on a timelapse clip I inserted in my video, this shows 30 fps in the Properties tab, but if I play 1 second of it in the player, it goes back to 3 fps. However, I can’t tell how, but I managed to get it to play at 30 fps in the player even though it was recognized at 3 fps in Properties. Then I clicked on other segments and played them, and when going back to this particular clip, it played at 3 fps. So it seems to me that Shotcut is unsure if the clip is 3 fps or 30 fps and displays/uses one or the other depending on what is happening beforehand.

This would maybe explain why it manages to Convert back the clip to 30 fps with the original frames. If the clip was really imported at 3 fps (the hard way) this should be impossible. So somehow the information is here and Shotcut knows it but it gets confused - but not all the time !

I hope this makes sense, maybe this behaviour is expected according to the changes documented in the first answer.

Note : I deactivated HEVC in my camera app to test another codec, same behaviour.