Performance in 20.02.02 Beta

[Earlybite]

Hi,

I Know, I know… I have a 2 core / 4 thread CPU, and with many filters… (no issue!).

But, look at this and this is all the time, what I really meant:

Shotcut is 20.02.02 Beta…
The part, beginning at the seeker is a normal MP4 file, exported with Shotcut at 85% quality. [1] And has no active filters (I can also remove them, doesn’t matter).
Placing the seeker in this part needs 4<!> seconds to complete! Only placing! [2]
Preview starts smooth, but after ~ 1/2 second it is stuck, really and simply stuck, for about 2 seconds, then again some frames, and again it is stuck.

+++
[2] This part is a cut from a longer part (see [1]), and other cuts from the same longer part have a smooth preview and by far not such a long time for only placing the seeker.
+++

But this happend also with other parts…, the same or nearly.
I had also a part, with that kind of behavior, that I have replaced with the “original” from the Playlist (is meaning deleted and new from the Playlist) and from that on…the Preview for that part was smooth, and is it still.

And it often happen, that the Preview runs one time smooth, but only one time!
(If someone wants to remember, times ago I already wrote about that ‘only one time’)

And to better understand, what my intension is:
Especially for that part…, it is fast and the cuts are short and hard. And I am not able to compensate that behavior by brain, impossible. And it pulls me out of the video, the making, the depth (you know what I mean?).

---------EDIT-----------------
BTW:
I really hope it will be taken seriously, because it is really the last time, that I will have written about that.
++

Best regards
Earlybite

[DvS]

@Earlybite:
Better put that thread in here as mentioned:

V20.02 BETA is now available to test

Rules of Participation (Important) We are only interested in major regressions over recent versions (v19.10 and newer). We are also interested in major bugs in new features and changes specific to this release. Do not report about existing bugs that have not been indicated as fixed by this version. Not everything reported will be fixed before release; only what the developers consider critical. We are not trying to fix everything possible during the beta but only the most critical, blocker bug…

[DRM]

@DvS

Better put that thread in here as mentioned:

I believe he is taking @Austin’s suggestion to him to make a separate thread to continue talking about this topic:

@Austin

Let’s open a new topic if you want to discuss further to avoid cluttering this beta conversation.

[DvS]

Ok.

[Austin]

These stutterings are expected behavior given your overall setup:

• Requiring 4 seconds to place the seeker tells me with 95% certainty that your media is not edit-friendly. The two options here are to Convert to Edit-Friendly for all your media, or go to a proxy workflow where the proxies will be edit-friendly by nature.

• There is a 2x speed boost on a clip. That means the non-edit-friendly video has to be read twice as fast as normal to keep up with the demand for new frames. There is no way your processor can keep up with that.

• Preview Scaling is not going to give you the greatest benefits unless the scaling mode and the input videos are basically the same size (or smaller). You’ll need proxies for best effect. They will be an absolute requirement if you stay with the 4-thread processor and continue layering this many effects.

[Earlybite]

@Austin

• Requiring 4 seconds to place the seeker tells me with 95% certainty that your media is not edit-friendly. The two options here are to Convert to Edit-Friendly for all your media, or go to a proxy workflow where the proxies will be edit-friendly by nature.
• There is a 2x speed boost on a clip. That means the non-edit-friendly video has to be read twice as fast as normal to keep up with the demand for new frames. There is no way your processor can keep up with that.

It is an exported clip with Shotcut, 1920*1080 at 60 FPS, at 85% quality.
It is only at this part [Pic-2]…

From that exported clip:

Seeker time == At Once [Pic-1]:

Seeker time == 4 seconds [Pic-2]:

I had extra made that separate project where I make the “Heavy Loads Parts”, to export it as MP4 file, to import it into the main project, that I have definitely for this a smooth preview…

And currently it is like this: As soon as the seeker “hits” the part, to see in [Pic-2], the preview stops for ~ 2 seconds. Then, more or less smooth (scratching?, can I call it scratching).

After that export I’ve even made another export from that “Heavy Loads Parts” project with only 20% quality, but at once I had stutter at the point you can see in [Pic-1]…

BTW: The export with 20% quality needed nearly the same time (~ 30 min. at 02:50 min.), as with 85%…

Thanks for your interest.
Best regards

[Earlybite]

V4:

The clip before the clip where the seeker is:
Smooth preview

The clip where the seeker is:
Stutter

Both clips are from the same video clip, only with a cut…, and both have the same properties.

Shrug?

Best regards

[Austin]

@Earlybite

It is an exported clip with Shotcut, 1920*1080 at 60 FPS, at 85% quality.

Unfortunately, this will not solve much unless the clip was exported in an all-intra intermediate format. Exporting as YouTube or H.264 MP4 at 85% (or even 20%) is still not an edit-friendly format. It will be as difficult to decode as everything else. Also, previewing at 60fps is going to overwhelm your 4-thread processor even further. So when it hits a 2x section, your computer will have to decode 120fps in order to meet the demand for frames. You’re asking your computer to do a lot of stuff. Do you especially need 60fps? You could double the performance by using 30fps if it is sufficient for your needs. But overall, if you were thinking of buying a 12-thread processor, it sounds like it would make your life a much happier place. That, and/or a proxy workflow.

@Earlybite

Both clips are from the same video clip, only with a cut

When a format is called “not edit-friendly”, that means there is a “keyframe” which contains the entire image, then there is a series of “delta frames” which only record the pixels that changed from frame to frame. This compression scheme relies on the tendency of frames to not change a huge amount from one to the next, and they save space by recording only what changed rather than re-write the entire frame every time. The default export will produce a string of 149 delta frames before creating a fresh keyframe (although this can vary depending on frame rate).

Now here’s what that means for the decoder… If you cut a clip immediately after a keyframe, then the decoder only has to decode the keyframe plus a couple delta frames. That’s pretty fast. But if you cut at the 147th delta frame, the decoder has to locate the keyframe before it, then apply 147 delta frames in order to reconstruct the frame you’re looking up. That’s why these formats are called “not edit friendly”. You can’t look up the exact frame you care about… you must reconstruct it from all the frames prior to it. This is computationally expensive (meaning slow and causes stutter). It also makes seek times and playback have random performance because it’s all dependent on how far away the frame you want is from the nearest keyframe.

If you like the workflow of exporting a section then pulling it back into another project for more layering, then perhaps exporting in an edit-friendly format would help a lot. “Edit friendly” means that every frame is a keyframe. Some options would be the DNxHD or ProRes presets under the “Intermediate” section in the Export panel. What we really need is a DNxHR HQ option… maybe you’ve inspired me to make a preset for that and submit it for inclusion.

[Austin]

I made the export preset. Try exporting in DNxHR HQ as described below and see if performance improves when you pull the clip into another project.

DNxHR HQ export preset is available

I’ve created a DNxHR HQ export preset for anyone seeking an alternative to ProRes for high-quality intermediate multi-generation encoding. The advantages compared to ProRes are: File size is only 64% of an equivalent ProRes file Encoding takes 44% less time than ProRes Picture quality is visually lossless, equal to ProRes HQ. The time and space reductions happen because DNxHR HQ is 8-bit whereas ProRes is 10-bit. However, Shotcut is currently 8-bit, so time and space are wasted by ProRes a…

[Earlybite]

I just gave it a quick go, and it seems…, …, …, is meaning…, currently…

One question <of course >:
What quality?
The original file size is 18,1 MiB, the converted file size at ‘Medium’ is 686,9 MiB.
Can I maybe also use the lowest setting, without loosing to much quality compared to the original quality?
(I have currently not much free disk space available…)

[Austin]

@Earlybite

‘Medium’

Hmm, where is “Medium” being set? Can you send a screenshot? DNxHR HQ doesn’t make use of any Medium setting. If you’re referring to the “100% quality” parameter, that always has to be 100% for the codec to use its full data rate. Anything less and it won’t be visually lossless and will fall apart fast.

These files are going to be large. That’s how big the data really is. The fact that your source video is 2.6% of the DNxHR size tells you how much compression is happening on your MP4 video data, which is also how much decompression your computer is having to do real-time when you play it back. That’s why it’s so slow… it’s having to reconstruct (decompress) an enormous amount of video real-time, which eats up your already-limited CPU very quickly.

[Earlybite]

Ok, it’s not (directly) called ‘Medium’…, it was DNxHR/ALAC MOV (better).
I’ve now tried with ‘good’ / ‘middle’ H.264/AC-3 MP4…, but the converted file is still ~ 8 times bigger than the original (ca. 110 MiB, ca. 900 MiB).
If I should have to do it for maybe 30 video clips…

But…, it looks that it really works better. Currently no stutter or even stops with a converted file.

I will see, what is currently possible for me with my maybe 50 GB free disk space…

In any case: Big thanks to you for your effort!
Just thinking about a sentence you often can read, if you search for a video editing software: Video editing made easy.

Best regards

[Earlybite]

Just one more word on this topic: It is a difference like Day&Night!

SMOOTH!

[Austin]

@Earlybite

Video editing made easy.

Oh yeah, famous last words.

I take comfort that interesting work is usually hard work.

Glad it’s working for you!

If you install the DNxHR export preset I mentioned on the other thread, then you can export a project directly to that format and not spend double time converting it to edit-friendly after export. You’ll also get higher quality since you skip a conversion step.