I was assuming that shotcut 18.x would be faster than the 17.02.05 version used in the fire escape benchmark that @nwgat created and wanted to test just how much. In doing so I’m somewhat suprised as it seems the current version (18.09.16) is slower on the x264 export than 17.02.05 was. I know “Something” has changed since the output files are different sizes(18.09.16 produced a slightly larger x264 output than the old version) despite having the same raw y4m input as well as the same output settings. I’m currently running the x265 export and will upload the full folders as .7z files to gdrive to share when it’s complete but I’m curious if anyone has any guesses as to what would cause this?
So The x265 exports are done, 18.09 was about 80s faster on a 5 run average than 17.02 but it lost with x264 data by about 100s Still uploading the folders for those who want the raw files
As promised here are the links to the files
The original fire escape
https://drive.google.com/file/d/1mC_amI-_Wte6pkrV_LCXZyAI4YGgM8si/view?usp=sharing
The modified version with 18.09 dropped in place of 17.02
https://drive.google.com/file/d/1jT8E3JEzZDuaokTQVeSOpusfDfavAVGP/view?usp=sharing
I am not very keen on going down this rabbit hole with you due to limited time and priorities. Progress is not all about performance, but I will give you my best guess. I see the project file is using the MLT dynamictext filter (simply called “Text” in Shotcut). This filter embeds a MLT compositor (called a transition in MLT terminology). It used to use the MLT composite transition, and I changed it to use the slower affine transition that is pending optimizations. I changed it to support animation - keyframes over the size and position - because composite’s support for that sucks. Composite has no sub-pixel rendering with interpolation, and its code is too complex and unwieldy to add it. It will be easier to optimize affine.
If you want to make a comparison without that change, then edit the project file to remove the <filter>...</filter> blocks that contain <property name="mlt_service">dynamictext</property>.
I don’t understand the graph, but I’d rather have a solid render than speed any day. I know many people bank on speed being a priority.
I 100% agree progress isn’t always about performance, and had the change been small(5-10s) I likely wouldnt have bothered to ask(I’m in no rush to use an old version and generally prefer x265 for storage/quality reasons over x264) but the quantity of the change jumped out at me(in this case nearly doubled time) Knowing that Affine is slower(but dramatically better) could easily explain it and if you could tell me what version you made the change with I’d be more than happy to test the version before/after if for no reason other than curiosity.I likely will with that change to the MLT files as well at some point this weekend.
Long story short the graph shows 17.02 exporting a project in 132 seconds and 18.09 exporting the same project in 231 seconds with the same settings, I was curious knowing we had moved to ffmpeg 4.4 what performance changes there might have been and was shocked to see such a large slowdown however @shotcut may have identified a change to one of the filters in the project as the culprit and I’m going to re-evaluate it knowing that.
v18.05 with the addition of Keyframes is where the change was introduced. Previous version is 18.03, but it has FFmpeg 3.4 whereas v17.02 used FFmpeg 3.0. Also, every Shotcut version uses the latest stable version of x264 and x265, whatever they happen to be at that time.
@shotcut it looks like the change was in 18.07, it actually got better in 18.08 and worse again in 18.09(not 100% sure why on that one) @Hudson555x I hope this graph is a bit easier to understand I took time to label it a bit better(or at all, I was lazy first time around)
You are correct because the Text filter did not get keyframes right away. It is mentioned in 18.07 announcement.
That was what I noticed when poking through the releases as well. I guess I’ll keep an eye out for improvements to affine. On a more disappointing note the change to ffmpeg 3.4 didn’t really help the early 18.x builds which is what I had hoped to see.
This topic was automatically closed after 90 days. New replies are no longer allowed.