Stuck exporting 99%

[ndq0345934]

Recent versions of shotcut failing to finish/close the export, stuck at 99%.

Export type is “Youtube” + modifications:
2560x1440
16:9
30 fps
progressive
Deinterlacter Best
interpolation: Best
h264_vaapi
quality based: 92%
GOP: 15
Sample 44100
aac
bitrate 96k

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 -KILL option.

Tried turning off Hardware encoder, no change. Tried turning off Parallel processing, no change.

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

20190831_youtube_001_anon_LOGO____01_Intro.mlt

[shotcut]

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.

[ndq0345934]

yes, 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.

[ndq0345934]

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:

movflags=+faststart
preset=fast
frame_rate_num=50000000
frame_rate_den=1000000
f=mp4
acodec=aac
channels=2
ar=48000
ab=128k
vcodec=h264_vaapi
qscale=4
g=25
bf=2
vprofile=main
width=2560
height=1440
aspect=1.77778
progressive=1
top_field_first=2
deinterlace_method=yadif
rescale=hyper
threads=0

i purged:

movflags=+faststart
preset=fast
frame_rate_den=1000000
vprofile=main

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.

EDIT: with movflags=+faststart worked, so it’s one of the remaining three.

[ndq0345934]

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.

Shotcut-190914.glibc2.14-x86_64.AppImage
Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

[ndq0345934]

just tested: added numerator and it succeeded:
frame_rate_num=50000000 (added)
frame_rate_den=1000000 (already there)

[shotcut]

@ndq0345934

i noticed version 18 put frame_rate_num in advanced tab where v 19.latest did not.

This is intentional. frame_rate_num and 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.

[ndq0345934]

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)