I’m on Windows 11, running Shotcut version 26.4.30 (checked for any updates five minutes ago & there aren’t any).
I’m editing a video using 1 audio track and 4 video tracks. The video is 4k.
On one specific section of the timeline, when the playhead gets to a new clip on video track 2, it pauses & lags for about a second before playing the clip. The clips are all relatively short, but none of them are under half a second. They are not grouped together.
On the other tracks and on different sections of this track, sometimes it lags, sometimes it doesn’t. But it consistently lags for this one set of clips. None of the clips anywhere in the project are grouped together.
I tried letting it play through that section of the timeline a few times in a row, but it still doesn’t smooth out. I closed and restarted the program multiple times. I restarted my computer. I checked again for Shotcut updates. I created a new video track and just moved those clips to the new one. I’ve opened other Shotcut projects, including other ones that are using the same 4k base file and/or which have far more video and audio tracks, and none of them seem to have the same issue.
I’ve attached a screen capture of the issue. Video tracks 1 & 2 are playing. You can see how when the playhead gets to the start of a new clip, sometimes it lags, sometimes it doesn’t, but then when it reaches the set of 4 clips at the end (about 00:22 in the screen capture video), it pauses for a long moment before playing each clip.
Please advise. I’ve had such a good time and a good experience using Shotcut thus far and I cannot figure out what I’m doing wrong to make it lag like this.
This happens because you are using 4K, not using optimized media, preview scaling, or proxies, and Shotcut does not aggressively read-ahead buffer: 25 frames and up to fps.
How do you know it is not enough? That is not the only factor here. Keep in mind that the read-ahead buffer is flushed upon any seek and needs to decode faster than realtime to fill. 4K is not hardware decoded because it is too much data to copy (see the FAQ). Preview scaling needs to be on for that. Yet another factor is clip caching. Not every clip in the project can keep open its file and threads because then the app can run out of handles from the operating system (and taking memory). Only 2x #tracks are kept open, subject to random access. Another factor when not using optimized (edit-friendly) media or proxies is the source clip is how the clip’s start frame correlates within its GOP, open or close GOP, number of references and B-frames, and if variable frame rate. Those all require decoding prior to the start frame.
Shotcut’s design does not require steps to get started including filling forms and importing media–whether a “bin" or conversion. But a lot of video is not edit-friendly, and you make a sacrifice or tradeoff: convenience vs. preparation.
For those who want more or better than I have already done, you need to work with the source code yourself and try instead of asking me. It’s not as if I have not tried.
I should have given more context here (and I was also a bit ignorant on the complexity of my question): I was thinking more on the lines of general RAM usage to have an option to make Shotcut not release the timeline (playback?) buffer as soon as possible (I see you mention that it’s released on any seek action, I did not know that, I just assumed it decides on a certain max size depending on free RAM and uses some sort of LRU logic to cleanup old stuff).
I’m probably way off on the wording here but I think that’s what OP also means by: “I tried letting it play through that section of the timeline a few times in a row, but it still doesn’t smooth out.” basically he expects that the “1 second look-ahead buffer” you mention to be like let’s say 10 seconds, and if you immediately try to replay that section it will just serve the already cached stuff.
Only if it’s very short, but instead, if it’s whatever fits in a few GB of ram, say 10-30 seconds, a user could pause the playback for some other reason (even intentional) and then on resume, it’s all prepared in the background and can play smoothly.
Note that I assume you already tried multiple variants on optimising this and some parts of my suggestion either require major redesign, specific editing patterns, complex guessing or just too much RAM.
Ideally what I was actually thinking when I wrote my initial reply is an automatic way of what I’m usually doing on filter heavy projects - let’s call it a “full timeline proxy”: I do a quick export of the timeline then load that .mp4 into a top level track and hide everything else below. This way no matter if I have an SPR + some text filters on a 50x sped up gopro clip (so even disk read would be an issue), the playback is smooth and I can cut/change stuff as needed with very little lag - the downside is I don’t see the changes unless I hide my top track.
What you are describing is a general render buffer that MLT and Shotcut does not have. A render buffer is often also disk-backed to make it larger. Shotcut only has a short read-ahead playback buffer.
This is an important point that i want to emphasize. With the playhead hits that new clip, Shotcut might need to decode 70 video frames before it gets to the desired frame (unless that clips starts at frame 0 - then it might only need to decode a few).
As a simple test, it would be very interesting if OP could click on the file, choose “Convert…” in the properties panel, and then report back if the converted file plays more smoothly. Even if you do not want to use edit-friendly files, it would be interesting to know the results for this discussion.
The GOP explanation makes sense. Using “Convert…” as a test seems like a good way to check whether the lag is mainly caused by decoding the source media.
