Recent versions of shotcut failing to finish/close the export, stuck at 99%.
Export type is “Youtube” + modifications:
quality based: 92%
Linux 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:04:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
qmelt staying active consuming ~23% to ~25% CPU even after job aborted and Shotcut closed. i can only
kill with the
Tried turning off Hardware encoder, no change. Tried turning off Parallel processing, no change.
Shotcut-190816.glibc2.14-x86_64.AppImage stuck 99%
Shotcut-190715.glibc2.14-x86_64.AppImage stuck 99%
Shotcut-190615.glibc2.14-x86_64.AppImage 100% successful.
Shotcut-181223.glibc2.14-x86_64.AppImage 100% successful.
I dismantled my project to the very first part to provide the simplest project that fails:
If you have movflags=+faststart in Export > Other (default for mp4-based presets), then it may spend a lot of time at the end to reorder the output file. This is expected. How long did you wait before trying to kill it? Did you try without hardware encoder? I suspect that quality level is high for a hardware encoder. Did you try with parallel processing enabled in Export > Video? I need you to test further and answer those questions before I take a look at your project.
movflags=+faststart is indeed in my encode preset. I would leave it hours, even overnight 8+ hours for verification. tried with and without hardware, with and without parallel. i always export at 90 or 92% in the past (FPV Quadcopter videos. need high quality). that last 1% usually finished in seconds or at most less than 90 seconds if i had to speculate.
i will try without the flag and report back. EDIT> okay, so i tried without the flag, it worked, i added the flag back, it worked. i suspect that when i went to an older version of shotcut i saved the MLT, so something in it changed to make it work.
Now i will have to hunt for an MLT version that was only with the latest and re-test. … i will report back.
this is kind of annoying (not faulting anyone obviously); i’m getting different results on different computers.
i won’t go too much further into testing, but the preset had the following:
which made it go 100%
now i know to play with the advanced tab if i get stuck. but it is still weird that older versions went 100% without such.
movflags=+faststart worked, so it’s one of the remaining three.
not solved alfterall
removing stuff from advanced tab has failed me all morning, finally exported w/ version 18.x.y just to get finished.
i noticed version 18 put
frame_rate_num in advanced tab where v 19.latest did not.
i will test such later.
Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux
just tested: added numerator and it succeeded:
frame_rate_den=1000000 (already there)
This is intentional.
frame_rate_den are normally dictated by what is in Export > Video > Frames/sec. If you add them yourself to Other, then Shotcut respects that as an override.
There was a bug in 19.x.y versions prior to 19.07.15 that would not apply the frame rate in your preset.
It seems that with my older understanding of quality at 90-92 percentile and the newer ffmpeg changes where vglobal is corresponding to crf, then making “quality” (vglobal) a lower number 65%-70% is the real solution.
where 90% on the new variable is too much (and visually useless) for the encoding to handle and may take many-many hours, where it seemed to be stuck even after 8+ hours. some specifics in the advanced tab may have made the encoding finish, but it’s unclear why.
i “think” this is the final answer. (vglobal ~65 to 70% max)
This topic was automatically closed after 90 days. New replies are no longer allowed.