Avidemux Forum

Hi,

I would like my 5900X to be 100% used when I encode with Avidemux_CLI. Currently it is 50% used.


Here are my settings:

batch file
set avidemux="C:\Program Files\Avidemux 2.7 VC++ 64bits\avidemux_cli.exe"
REM %%~fI returns the filenames in subfolders
@echo off
for /R %%I in (*.mp4 *.mov *.mts *.ts *.avi); do %avidemux% --load "%%I" --run hevccpu.py --save "%%~fI.mkv" --quit;
del *.mp4 /s
del *.ts /s
del *.mts /s
del *.avi /s
del *.mov /s
hevccpu.py
#PY  <- Needed to identify #
#--automatically built--

adm = Avidemux()
adm.videoCodec("x265", "useAdvancedConfiguration=True", "general.params=AQ=30", "general.poolThreads=99", "general.frameThreads=0", "general.output_bit_depth=0", "general.preset=ultrafast", "general.tuning=none", "general.profile=main"
, "level=-1", "vui.sar_idc=0", "vui.sar_height=1", "vui.sar_width=1", "vui.color_primaries=2", "vui.transfer_characteristics=2", "vui.matrix_coeffs=2", "MaxRefFrames=3", "MinIdr=25", "MaxIdr=100", "i_scenecut_threshold=40"
, "MaxBFrame=3", "i_bframe_adaptive=2", "i_bframe_bias=0", "i_bframe_pyramid=1", "b_deblocking_filter=True", "b_open_gop=True", "interlaced_mode=0", "constrained_intra=False", "b_intra=True", "lookahead=40"
, "weighted_pred=2", "weighted_bipred=True", "rect_inter=False", "amp_inter=False", "limit_modes=False", "cb_chroma_offset=0", "cr_chroma_offset=0", "me_method=3", "me_range=16", "subpel_refine=5", "limit_refs=3"
, "rd_level=3", "psy_rd=1.000000", "rdoq_level=0", "psy_rdoq=0.000000", "fast_pskip=True", "dct_decimate=True", "noise_reduction_intra=0", "noise_reduction_inter=0", "strong_intra_smoothing=True", "ratecontrol.rc_method=0"
, "ratecontrol.qp_constant=0", "ratecontrol.qp_step=4", "ratecontrol.bitrate=0", "ratecontrol.vbv_max_bitrate=0", "ratecontrol.vbv_buffer_size=0", "ratecontrol.vbv_buffer_init=1", "ratecontrol.ip_factor=1.400000"
, "ratecontrol.pb_factor=1.300000", "ratecontrol.aq_mode=2", "ratecontrol.aq_strength=1.000000", "ratecontrol.cu_tree=True", "ratecontrol.strict_cbr=False")
adm.audioClearTracks()
adm.setSourceTrackLanguage(0,"und")
if adm.audioTotalTracksCount() <= 0:
    raise("Cannot add audio track 0, total tracks: " + str(adm.audioTotalTracksCount()))
adm.audioAddTrack(0)
adm.audioCodec(0, "copy")
adm.audioSetDrc(0, 0)
adm.audioSetShift(0, 0, 0)
adm.setContainer("MKV", "forceAspectRatio=False", "displayWidth=1280", "displayAspectRatio=2", "addColourInfo=False", "colMatrixCoeff=2", "colRange=0", "colTransfer=2", "colPrimaries=2")

Thanks

One limiting factor is the ultrafast settings, but in your case probably the decoder is the bottleneck. If you dont use hw accelerated decoding, make sure multithreaded decoding enabled.

With "useAdvancedConfiguration=True", preset is not evaluated, but with "general.frameThreads=0" which lets libx265 decide how many frame threads to use, it will spawn up to 6 threads*. With 12 CPU cores, this would mean ~50% of the capacity. Decoding may play a role depending on the codec and resolution, but I would not expect this to be a major factor here.

Regarding multithreaded decoding, please be aware that this setting controls only the behaviour of the bundled libavcodec library. Other decoders like e.g. libaom for AV1 do their own thing.

*) I quote from the header file:

    /* Number of concurrently encoded frames between 1 and X265_MAX_FRAME_THREADS
    * or 0 for auto-detection. By default x265 will use a number of frame
    * threads empirically determined to be optimal for your CPU core count,
    * between 2 and 6.  Using more than one frame thread causes motion search
    * in the down direction to be clamped but otherwise encode behavior is
    * unaffected. With CQP rate control the output bitstream is deterministic
    * for all values of frameNumThreads greater than 1. All other forms of
    * rate-control can be negatively impacted by increases to the number of
    * frame threads because the extra concurrency adds uncertainty to the
    * bitrate estimations. Frame parallelism is generally limited by the the
    * is generally limited by the the number of CU rows
    *
    * When thread pools are used, each frame thread is assigned to a single
    * pool and the frame thread itself is given the node affinity of its pool.
    * But when no thread pools are used no node affinity is assigned. */
    int      frameNumThreads;
X265_MAX_FRAME_THREADS is defined as 16, but the x265 video encoder plugin in Avidemux allows 4 threads max as a user-defined value.

Quote from: eumagga0x2a on December 16, 2021, 10:52:32 PMit will spawn up to 6 threads*

something is not right here, on a 16 thread CPU with medium preset it fluctuates between 1200 and 1600 % CPU usage (estimated decoder CPU usage no more than 100%)

Quote from: szlldm on December 16, 2021, 11:12:54 PMsomething is not right here

This is easily possible, I didn't check whether the comment in the header matches the actual implementation in the x265 source.