Multithread support for postprocessing with ffmpeg

[STonEDSTonE]

Checklist

• I'm reporting a feature request
• I've verified that I'm running youtube-dl version 2020.05.08
• I've searched the bugtracker for similar feature requests including closed ones

Description

When I use youtube-dl to download audio (ogg), it converts the video to audio via ffmpeg.
ffmpeg itself has multithread support, but it is not active when called by youtube-dl for some reason.
I searched for multicore support and only found #1125 which is closed, but the provided solution (--postprocessor-args "-threads 3") does not work.

My VM has 4 Threads to work with, and i tried the following:
youtube-dl --extract-audio --audio-format vorbis --audio-quality 0 --postprocessor-args "-threads 3" --metadata-from-title "%(artist)s - %(title)s" -o ~/Schreibtisch/%(title)s\ -\ %(upload_date)s.%(ext)s URL
I also tried different "places" for the postprocessor-args within the command, none of those trys worked.
Someone can give me a hint what i am doing wrong? Or is this not working at all?

The main request would be to make multithread support the default since todays processors have multiple threads available. So this would improve the performance for majority of users.

[dstftw]

--postprocessor-args "-threads 3" is passed to ffmpeg and works just fine. The number of actual threads to be used (if any at all) depends on ffmpeg and particular output.

[STonEDSTonE]

@dstftw then would you be so kind and tell me how to use --postprocessor-args "-threads 3"? Since youtube-dl --extract-audio --audio-format vorbis --audio-quality 0 --postprocessor-args "-threads 3" "$URL" only uses one core (at least not on my system) while a normal ffmpeg convert like ffmpeg -hide_banner -loglevel error -stats -y -i "$OLDFILE" -c:a libvorbis -qscale:a 5 -c:v libx264 -preset veryslow -crf 22 "$NEWFILE" < /dev/null uses all four cores of the VM. I just tested it again to make sure (Linux Mint 19.3 with ffmpeg 3.4.6).
Just saying "it works for me" and closing is a bit unhelpful to say the least.

And since you closed the case without saying anything to the feature request "make multithread a default" part, does this mean that this does not make sense? Or why shouldn't that be the default?

[dstftw]

Have you even bothered to read it?
Again: how ffmpeg will use multithreading depends on particular command and output. If remove all video-related stuff from your command (that's completely useless in case of extraction audio) and put correct ogg extension for NEWFILE you'll will unsuprisingly get only one core used regardless of how many -threads passed.

[STonEDSTonE]

Yeah i did. But unfortunately i did not understand what that means.
But you gave me the right hint this time, I was comparing apples (video to audio) and oranges (video to video) without being aware that this could even be an issue. My fault was that i extract audio which doesn't seem to be multi-threadable in general. A ffmpeg -hide_banner -loglevel error -stats -y -i "$OLDFILE" -c:a libvorbis -qscale:a 5 -vn "$NEWFILE" < /dev/null also only uses one core.
Other way around, youtube-dl --recode-video mp4 "$URL" uses multiple cores by default.

So thanks for giving me another answer, now i am wiser and know that my problem can not be solved and doesn't have to do with youtube-dl.
And if we are lucky, maybe this will help someone else too :)