Jerky Video in timeline

i downloaded Shotcut to edit and render videos in 2.7k and 4k.
But the video in the timeline is very slow and jerky … I think my PC just is not good enough … is it possible to reduce the quality of the video (in the timeline), so i can work fluent?
If I render the video, it should be in good quality afterwards…

Besides, can you suggest any good basic tutorial? Videos from Youtube?
Greetings from Germany,

There is no ‘proxy editing’ feature for shotcut.
Jerky playback may occur even with lower resolution ‘proxy’ files because [a] System requirements don’t match hardware and [b] Combination of filters, edits, number of files and timeline tracks.

The exported result will however be fine.

You can go into “SETTINGS” and switch off “Realtime (frame dropping)”.

The timeline playback should be smoother, but will of course NOT be in real-time.

Again, the EXPORTEDvideo should be fine.

For tutorials see:

I’ve never found this setting to make any difference. 1080p video is fine either way and 4K is laggy on or off.
[4k is smooth in Davinci Resolve however[

There is a way to do proxy editing but it will take some manipulation of the video and mlt project.

  1. Render video into a smaller file; preserving framerate but not dimensions… ** Use ffmpeg or ShotCut export **
    Example. MPEG2VIDEO, 640x360 : MP2AUDIO, 64k - Save as THISVIDEO.mpg
  2. Open .mlt project file (using notepad or text editor) and change the video files to match the THISVIDEO.mpg Make note of Video files and path and save
  3. Make your edits in ShotCut using .mpg and save
  4. Open .mlt project file (using notepad or text editor) and change the video files back to original files and save
  5. Open ShotCut and load project to export

Take a 60s clip of something and practice a few times. You can edit very high resolution quite easily when you get this simple process down. Make sure you save the smaller file in the same directory so you only have to edit the file, not the file and file paths.

Here is typically how I name my files when I do this.


By doing so, only have to change .mp4 to -Proxy.mpg throughout the MLT project before, and -Proxy.mpg to .mp4 when I am done.

1 Like

There’s no need to edit the .mlt with this kind of trick.
It’s easier just to close Shotcut, reverse the file names and then re-open the project for export. I’ve done this several times and works fine.
But as I now use DaVinciResolve for either 4K footage or lengthy projects it’s not an issue for me on the hardware I have.

1 Like

In the mlt file there is a hash value (property name=“shotcut:hash”) for each producer element, and it is calculated from the source file (it is an MD5 hash, but only from the first and last MB of larger files). I was worried it was important, so when I wanted to switch a source file I manually calculated the hash (using an external utility, or by adding the new file in a temporary Shotcut project and taking note of the calculated hash value in the mlt file), and edited the mlt file to set the correct hash value for the new file. From what I read here this is not necessary, Shotcut does not care if the stored hash is not matching?

The hash is used for a couple of things:

  • when a file is missing to determine if the replacement file offered is the same (gives yellow warning symbol in the dialog when not)
  • as a key for looking up cached thumbnails and audio levels

Not only does disabling Settings > Realtime disable dropping video frames (normally done to try to make audio continuous) but also it enables additional parallel processing for effects (when not using GPU Effects). Of course, the results depend on the workload you give it, which has many factors. It is not always able to max out all your cores as there are different forms of parallelism in both FFmpeg and MLT: image slices, multiple frames, SIMD instructions. This (disable Realtime), in particular, enables frame parallelism in MLT (same as Export > Video > Parallel processing), but it is intentionally limited because there is overhead, RAM cache depletion issues, locks in various places of code due to lack of concurrency, and the need to reserve some resources for the slice-based parallelism and Shotcut’s threads.

I’ve been trying to calculate the same md5 hash for “shotcut:hash” on the command line and in my language - but to no joy so far - the value differs from the one shotcut uses. Could you let me know what external utility you used - or what I could use on the command line to generate the same?

I made a script in PowerShell for my use case, but its been a while since I’ve used it so it may or may not still work. What it did was, for files less than 2MB (2.000.000 bytes) calculate a plain MD5 hash of the entire file, and for larger files it read the first and last 1MB of the file and calculated a MD5 hash from that. Do you not get matching md5 not even for small files? What os are you on?

See here and take your pick.

Yes - I get a different md5 even for small files. I’m trying to do the same algorithm as you describe. I’m on OSX - but even when I do md5 -q filePath I get a different result to that in Shotcut.

Sure, for files less than 2MB these are fine (I’ve been using FSUM and HashMyFiles myself, as well as PowerShell’s Get-FileHash). But the “first+last 1MB” hash calculation for larger files, if shotcut is still doing that, is not standard, and generic tools will not create a matching hash.

@shotcut I just checked the shotcut-win64-200412.exe Windows binary I downloaded last month and the checksums (both MD5 and SHA256) do not match the ones given in the text files on the GITHUB page. Maybe there was a mistake calculating them, or copying them to the text files.

The MD5 in the txt file on Github says:

ad48b63e36237f45357b26366a3c3e46 shotcut-win64-200412.exe

on my system it calculates it as:

B0D0B5B5F574B96110CEF47E81AFDD05 shotcut-win64-200412.exe

P.S. @opn You should have started a new thread for this issue and not use an old one that is unrelated to the problem.

I just downloaded both the exe and checksum text files, checked them, and they are correct. Closing this thread now.