News:

--

Main Menu

Thread count not respected

Started by Jean Delvare, December 24, 2017, 07:08:34 PM

Previous topic - Next topic

Jean Delvare

I am using avidemux 2.7.0 on Linux (openSUSE packman package) to encode h.264 videos. There are two places in the Qt GUI where I can select the number of CPU threads which will be used: Edit > Preferences > Threading and Video Output > Configure > General. I have set both to 4, however 12 threads are being used by the x264 video encoder plugin (which is the default for 8 logical CPUs.) I checked the actual value with mediainfo on the output file.

Firstly a question: why are there two settings controlling apparently the same thing?

Secondly, I think this setting used to work before, so any chance it can be fixed so the requested CPU thread count is honored again?

Rationale: I'm using my computer for other tasks while encoding in the background. With 12 encoding threads my machine is lagging and is unusable for anything else.

Thanks,
Jean

eumagga0x2a

#1
Quote from: Jean Delvare on December 24, 2017, 07:08:34 PM
I am using avidemux 2.7.0 on Linux (openSUSE packman package) to encode h.264 videos. There are two places in the Qt GUI where I can select the number of CPU threads which will be used: Edit > Preferences > Threading and Video Output > Configure > General. I have set both to 4, however 12 threads are being used by the x264 video encoder plugin (which is the default for 8 logical CPUs.)

The one in the x264 plugin should be fixed by [x264] Fix threads setup. The very same bug existed in the x265 encoder plugin, now fixed as well.

Thank you for your report.

QuoteFirstly a question: why are there two settings controlling apparently the same thing?

The value set by the first control is not used (either not yet implemented or an old implementation removed without removing the control as well), it would have set the number of threads for the internal libavcodec ("lavc"). The scope of the second setting is limited to the libx264 encoder.

Being a Linux user, you could trivially build Avidemux from the current git master containing the fix.