Hi,
I don’t know why oh why the rendertime in version 19.10.20 is very much longer than in the previous version 10.09.14?
I used the same PC WIN7, i5, 32GB RAM, the same Project with the same output settings and no other program in the background.
19.10.20:
19.09.14:
There was a fix to make keyframes thread-safe on frei0r-based video filters (that probably does not mean much to you, but there are a lot of them). I suspect that is the reason, but I have to do some tests when I return from a vacation to confirm that.
Ok! “Happy vacation”!
I have not reproduced the problem in one of my projects tested with and without hardware encoder. In both cases, 19.10 was one second faster. Are you heavily using certain filters or track blending to help reproduce?
Yes, in both versions I used the same filters and the same filmclips.
And there are lots of filters I use:
A1: only ‘fade-out’ in the clip.
V1: 2 ‘mask from file’, 2 ‘text: html’ Webfx ‘cube’ (from 36 GL-transitions), ‘two-pass normalise’ and ‘color-grading’ for each clip. aprox. 30 cuts with 15 frame-length ‘clock’-transitions.All are clip-filters.
V2: 2 ‘mask from file’ in the textclips.
V3: only layerfilters: ‘postion&size’, ‘glow’, ‘opacity’. The layer blend mode is set to ‘screen’.
I made a test where I added this on a new video track with screen blending in one of my somewhat complex projects that is 2:28 minutes. In version 19.09 it took 6:09 to export. In version 19.10 it took only 4:22.
My project is not using Mask:From File. I made another test with that included on the clips in the video track I added. In version 19.09 it took 4:13. In version 19.10, it took 4:06. These times are shorter than previous tests because the clip Mask filter created less work for the track filters and blending.
I did not test with WebVfx cube because:
Like another performance regression report and my subsequent tests, I am not reproducing it, and it is probably due to a specific combination of things in your project. I decline to profile other peoples’ projects at this time. If the regression is where I suspected as mentioned in my first reply, I have not run into it with these tests, and the bug fix is very important to image integrity. General image-processing performance improvements are already on my road map.
I will allocate what’s the reason of my long rendertime and report.
I have deleteted all my filters, except the 15fps fade transistions and colorgrading filters in V1. No ‘mask from file’ and no webfx-filter.
V3. Deleted completely.
But the render-time still needs very much longer than in the previous version I mentioned.
Thus, I suspect this, too.
I’m afraid, that I have to return to the previous version of SC. Almost 80% more rendertime for the exact same project in 19.10.20.
If you have a working hardware encoder, you should run a test a with that turned on. It may help determine if the problem is related to encoding or everything prior to that.
I never used the harfware-encoder before so I set it to h264_nvenc with the exact same encoding settings. The rendering was quicker indeed, but the result is poor. The quality of the film is more less without hardware encoding.
I think you missed the point of trying to narrow down the source of slowdown using a divide-and-conquer strategy. With hardware encoder turned on, run the export (preferably without WebVfx cube) in each version and report the times.
In another project without any filters hardware-encoding is quicker but also in a bad quality at this settings.
Of course, if hardware encoder is almost always faster than software encoding.
With hardware encoder turned on, run the export (preferably without WebVfx cube) in each version and report the times.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.
