Is anyone seeing a performance regression in 21.01.29?

I ran into what I thought was a performance problem on my new pc(finally upgraded from my t7500) and with it came the new 21.01.29 released the day before I powered it on, i’ve spent the past week watching shotcut freeze just trying to scrub through the timeline and running down various things that “might” be the problem(some driver tweaks, adjusting/removing my overclock changing the appdata folder to faster storage flipping between openGL and ANGLE) only to go back to 20.11.28 and find everything performing as normal.
I’m on a(nearly clean) install of 10 enterprise and with hardware to spare(dual e5-2667 v2 xeons, 256gb ddr3 and the project files are on the same 512gb nvme i’ve been using for a while) so i’m left with it must be something added(or changed) in 21.01.29 and wondering if anyone else has seen the same issue(could it be the high performance waveforms?) Has anyone else encountered this/found solutions I’m not thinking of?

1 Like

This is actually not new. That was added in version 20.10:

Improved the Timeline scrolling speed and smoothness (regression in v20.09).

What was added in version 21.01 was the option to turn that off because some people reported unable to see waveforms. The change in version 21.10 was to draw directly to a hardware texture, which has a limited size. Shotcut tries to determine the limit in a very conservative fashion; however, when there is a resource limit or exhaustion problem here it can lead to missing waveforms. Sadly, no one ever confirmed that turning it off fixed it for them.

Try to characterize the problem some more. You already said on scrubbing the timeline.
Is there a difference between a single track timeline with one long video or a timeline with multiple video tracks?
Is there a difference between scrubbing, scrolling using the scroll bar, or both?
Is there a difference when simply playing a high res or frame rate video in the Source player when using Automatic Video Mode?
In the questions above, I am asking about a difference between versions.

Did you see this from the release notes?

Improved the playback speeds of fast forward and rewind to not be so fast and more usable.

Is this the scrubbing you are talking about, better known as trick play? If so, that is intentional.

I can not say that I have noticed anything different, and with every release there are always people saying performance is worse.

Well I can’t see any performance lag or regression in my shotcut its even running faster than the old version in My computer. Well you can also see my specs:

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.

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 :pensive: 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