I think It’s running fast because of very high specs of my PC.
Maybe scrubbing was the wrong term, moving the playhead on the timeline either dragging or simply clicking somewhere. As for the resolution/framerate I typically record 4k29.970030 but it seems worse on some 2560x1440p60 footage I was sent, the number of tracks doesn’t seem to matter either it happens with 1 track or 4(the most I normally use)
I did see the release notes that’s why I asked about the waveforms that were defaulted to no, nothing else stood out that should have been capable of what i’ve been seeing
I took some time to record the 2560x1440p60 footage, you can see it lockup shotcut the second I click on the timeline on 21.01.29 but behave normally when I open it up in 20.11.28
This can’t possibly be a resource problem, my new PC is faster than my old one in every measurable way and that was cutting 4k29(and the 2560x1440p60 I used in my demo clip) on a regular basis
1 Like
Scrub is the correct term when dragging the playhead. Click to seek is very similar and can be considered scrub. Are you always testing with the same clip or same type of clip? Maybe the problem is specific to the way that clip or those clips are made that regressed. We had to make major changes to our FFmpeg integration. Share details about the source clip and maybe try with a short clip that went through Properties > Convert. Thanks
It’s the most noticable with that clip but I did see it on my standard 4k clips as well, no attempts at converting it were successful that I could find but I can give it another go, i’ll paste the media info for it, and what I normally use here
and my normal clips(that also exhibit similar but not quite as bad behavior)
I do not see a problem based on the MediaInfo screens you posted. For future reference, MediaInfo has a text mode that you can copy and paste - makes it easier to read. I just tested with some H.264/AAC in Matroska and did not have a problem. I saw your video, and that is a major problem and not just a small performance regression. But I am not positive I can fix it since I am not seeing that on any of my systems (4 machines, 3 operating systems).
I had a person show a similar major performance regression on versions 20.10 and 20.11 for him that we were unable to solve. Except he was not showing scrub and seek problems. He was selecting different clips on the timeline and showing a huge delay for the timeline to reflect selection and the Properties or Filters panels to update. It could be the same but different test methodologies.
Do you see the same seek and scrub performance problem when you do not use Timeline and simply open a clip to play it in the Source player?
Now, repeat the same test, but ensure Video Mode = Automatic.
Thanks
1 Like
I am also seeing this. Because for testing the other bug I have been jumping back and forth between 18.11.18, 20.11.28 and 21.01.29, it is very noticeable. 21.01 and 20.11 seem to be about the same.
The lag is most noticeable for me when I move a very long clip on the timeline, especially if I move it up or down to the next track. I can take a nice sip of coffee until the color returns to the clip and everything shows adjustment to the new reality.
If I move too quickly, and move a second clip while waiting for the color to return to the first clip moved, when that color returns to the first clip, the second moved clip jumps back to where it was, undoing the second move.
Coffee is good.
1 Like
The GOP looks pretty different. Does the 2.7K file scrub better if converted to a lower GOP?
It is one second with 5 B-frames, not super unusual IMHO.
Not unusual, just different. As in, potentially more effort to construct a seek frame than the 4K version. With of course any changes in ffmpeg itself rippling up to Shotcut’s perceived responsiveness.
We did not upgrade our FFmpeg version. However, we had to move off of some of their deprecated APIs to integrate AV1 and something else not exposed in Shotcut.
If you watch his video or in the linked related issue, there is a huge difference between the neighboring versions they compare - something I never experience even with challenging video… with one exception: 5.6K video from my GoPro MAX exported as CineForm. CineForm is very slow in our version of FFmpeg; it was supposedly improved recently. Of course, there could be other obscure codecs slow like this I have not come across as there are so many, but they are using H.264.
I still want to get an understanding if it is a media-related handling issue or timeline/GUI drawing issue, which is why I asked for the Source playback test.
Sorry for the delay(day job interrupted) the issue is not present just playing the video back it is only if the video is on the timeline
That was my theory at first, I spent time converting to a bunch of different formats(including outright uncompressed huffyuv which was huge!) and saw no changes
And just for the hell of it @shotcut I tried the recent unstable(the 21.04 alpha) thinking maybe something got broken/fixed upstream in a dependency and it behaves the same as 21.01.29
With Shotcut version 21.01.29, I don’t have scrub and seek problems. But still have my same problem which is when selecting different clips on the timeline there is a huge delay for the timeline to reflect selection and the Properties or Filters panels to update. I feel that " the more clips in project, the more delay".
So I have to get back to shotcut-win64-200927 
which is o.k. for my ASUS notebook.
Thanks for the update in your situation and trying the newest version. Sorry it has not worked for you.
@D_S did you try rebooting or a different choice in settings > display method?
1 Like
Yes I see the same results for opengl and angle, I didn’t try software(mesa) I use opengl normally, quadro cards typically have excellent opengl drivers
This is my impression as well.
In yesterday’s project I needed to have twice my usual number of tracks, and twice as many clips. So there was a noticeable difference from my “usual”.
1 Like
Shotcut-Versions: Speedy v20.11.28 - Slow v21.01.16 - Unusable slow v21.01.29
Using these Shotcut-Versions with Windows 10 Enterprise from the portable zip file with a 20 minutes 4K-mlt-script is a pleasure to work with in v20.11.28 consider speed of GUI and moving the playhead. Proxy preview x 540p is fast and easy.
But using the same mlt-file with v21.01.29 is horrible slow and lagy. Each click just opening a menu like “Edit” or “View” takes a second or two.Tried version 21.1.16, too. It is slow and lagy and proxy preview is stop and go.
Just the middle from new and old version.
Loading the mlt-file is very fast in v21.01 and moving a clip from one track to another for ex. is still very fast, this task is very slow in the old version 20.11.
But its the GUI which is slow to pain.
Tried opening the same mlt-file at the same time in both versions, using taskmanager to switch between the versions of Shotcut. RAM usage is only 6GB from 16GB available. CPU usage is at expected levels.
As said, reading the mlt-4K-20minutes file is lightning fast in v21.01 and takes very long in v20.11. But when the file is open then moving the playhead in the old version is agil and fast. Moving the playhead in v21.01 is slow motion at its best. Both versions use the same proxy files x 540p, cause its the same open mlt-file.
My hope was GPU GTX1060 with 6GB would help and GPU usage may be improved. But to enable the GPU for proxy-computing or final video export does not improve the speed at using the GUI during work.
I think I read in the update hints that QT now is fully envolved in the GUI in v21.01. So my guessing is a problem there if other OSs than Windows 10 do not have this GUI performance loss.
Tried again with very small video and only two tracks. The new version is there faster than ever …
The longer the videeo the slower Shotcut? Other difference is the video slow in handling having no playlist. All clips are directly drag-n-dropped into timeline.
There is a known performance problem running multiple instances of Shotcut at the same time.
Do not do that for now! I know at least part of the reason: the database file that holds the cache of the waveform data and thumbnails - even if those are turned off. I need to rewrite that to not use a database. The first instance of Shotcut will open the database and lock it. The second or more instances will not only have access to the cache, it will keep trying to use the database in case it becomes available.
I think I read in the update hints that QT now is fully envolved in the GUI in v21.01.
The Qt library has always been fully involved in the GUI. What has changed is the versions and therefore the APIs. For parts of the GUI, we used a category of API called “Quick Controls.” After a few years, a “Quick Controls 2” API was announced and the old one deprecated. In the current version of the library (upgraded in Shotcut v20.10), the old API is no longer supported, but we were still using it but we saw the warning. That did cause some problems with some multi-screen setups. The solution was to start migrating to the new API, which we did in Shotcut version 20.11 but not completely. If that is no longer supported then certainly using both at the same time cannot! Also, in the next version of Qt, the old Quick Controls 1 API is removed. So, for Shotcut version 20.01 we completely migrated to Quick Controls 2. I actually expect that all this combined with new and improved Windows build system would actually improve things. Maybe it has for some. There were always some systems on which Shotcut did not work or work well. Of course, while not ideal, being pragmatic, I expect that when there are big changes like that it will not work for some and improve for others.