Converting MP4 to stable framerate, continues to convert indefinitely past 100%


I’m trying to convert a MP4 into edit friendly constant framerate but the job continues past 100%. I’ve converted other similar MP4’s of similar length without this issue (they finish at 100%). I don’t want to wait indefinitely until it completes, if it even will, because it pushes my CPU usage to 100%. Having said that, is there also a way to throttle CPU usage? I’m not comfortable having my CPU running at max, my PC gets loud and hot. Does anyone know what safeguards the software has to protect the CPU from overworking and crashing?



We just had that topic about CPU usage and priviliges - just do a simple search for the last topics!
As for “constant framerate” i am not sure what you really mean - as far as i know all mp4 codecs use a constant framerate, probably you mean bitrate?

When I add the mp4 to the project, a window pops up asking if I want to convert the clip to an edit friendly constant framerate format, I’m not talking about bitrate. If I do the conversion, the job continues to run for a very long time past 100% which doesn’t make any sense.

And sorry I did a search for the framerate conversion topic but not for cpu usage topic. Before I dig deep into that question could you tell me if it’s possible to limit the cpu usage while converting or exporting videos?

Yes, it is - but i am not doing the search for you.

In what format is the clip you want to import into SC?
You have to make sure your ‘Video mode’ setting in SC is fitting to the format of your clip you want to import! Look for settings - video mode. Per default SC wants to adapt the video mode to the first clip you draw into the timeline. Honestly, i dont know of a codec that has not constant frame rate, instead you need to have a constant framerate to view you video properly otherwise the speed would change? That makes no sense at all!

Cell phones are notorious for creating variable frame rate videos. The metadata may say 30fps, but the actual number of frames per second could be anywhere from 0 to 30 and it will vary throughout the video. This is for space savings and computational efficiency for mobile devices. It’s also used by many screen capture programs because constant frame rate recording of a static PowerPoint slide is an inefficient use of disk space.

In a media container like MP4, there is a “master clock” called Presentation TimeStamps (PTS) that synchronizes all streams together. This is how video frames, audio samples, and subtitles are correlated to each other for a given timestamp at playback. PTS in MP4 usually has a resolution of 1/90000th of a second. Each frame of video is assigned a timestamp on that scale of 90000, not on a scale of 1/30th (30fps). This is what enables variable frame rate to work without the playback speed looking like it is ramping up and down. The frames are simply given PTS at whatever point in time a new frame is needed, whether it aligns on 30fps boundaries or not. Playback looks totally fine, but it is inconvenient for video editors to process because real-time frame duplication has to be done to pad up to the constant frame rate of the timeline, plus seek operations (especially backwards) get much more complicated. Hence, Shotcut offers to convert VFR to CFR.

Since VFR to CFR conversion is actually a behind-the-scenes call to ffmpeg, there is not a way I’m aware of to pass throttling information to ffmpeg. Conversion will cook the CPU. A third-party utilization tool like Process Lasso (for Windows) would be required to trap any ffmpeg calls and throttle them.

For exporting videos (not conversion tasks), set the Codec Threads in the Advanced panels to half your thread count to control heat.


Austin, this is what I’m talking about. The mp4 was made from a phone, the metadata says 30fps but shotcut recognizes it as VFR and prefers to convert it to actual CFR. Playback and editing is fine thanks to PTS, but shotcut really prefers to sync frames up on a CFR. So you can throttle CPU usage for final exporting, but not possible for the converting to CFR jobs. That really should be a global feature setting in SC to control CPU usage on all jobs, not just on exporting jobs. That’s a missed opportunity that would make SC a more robust software. And since it hasn’t yet been explained, I’m assuming the endless converting to CFR job process I’m experiencing is a bug. I’m not going to cook my CPU for an undetermined amount of time to see if the converting job ever finishes.

Regarding the conversion that goes over 100%, that’s a new one to me. Not sure what’s going on there. We might be able to find an answer if any job log is generated. If necessary, the file could be converted with HandBrake and brought in that way.

1 Like

It runs ffmpeg as a child process, which does not report a % but rather a frame number; so Shotcut has a guesstimate based on ffmpeg’s guestimated average frame rate and duration. However, since it is VFR, the only way to know is to run it.

Does anyone know what safeguards the software has to protect the CPU from overworking and crashing?

Like most software, none whatsoever, except maybe your OS has a temperature monitor and will do something like reduce CPU frequency or sleep. CPUs do not crash from overwork. Systems with a bad thermal design do, however.

So you can throttle CPU usage for final exporting, but not possible for the converting to CFR jobs.

I will add this to the To Do list.

1 Like

Thanks for the responses everyone. I can continue using SC for my projects since the concerns I’m facing aren’t deal breakers for me. I hope framerate conversions are more predictable and I’m looking forward to new features continually added to make SC more robust and consistent.

This topic was automatically closed after 90 days. New replies are no longer allowed.