x265 parameters and 10bit output support

[butterw]

with avidemux 2.7.6 x64 on win10.

1. In this thread, it was recommended to encode x265 with open-gop=0 command line option to avoid cutting issues
https://avidemux.org/smif/index.php/topic,19141.0.html
Is it possible to encode in avidemux with parameters not available in the avidemux x265 gui ?

2. I've tried re-encoding some x265 10bit content in avidemux. I'm using main10 Profile, it gets downconverted to 8bit. Is x265 10bit output currently supported ?

Finally, I typically don't use a case fan on my dual-core and I would like to limit the encoding to 3 threads to avoid overheating (I  only ever encode short clips and I monitor temperature so this works fine). In avidemux prefs I've set encoding priority to low and lav threads to 3, and x265 Frame threads to 1, but I'm still seeing cpu use go up above 95%. Is there anything more I can do in avidemux ?

[eumagga0x2a]

1. In this thread, it was recommended to encode x265 with open-gop=0 command line option to avoid cutting issues
https://avidemux.org/smif/index.php/topic,19141.0.html
Is it possible to encode in avidemux with parameters not available in the avidemux x265 gui ?

All usable parameters are members of the x265_settings struct.
It doesn't matter whether they are exposed via UI but they must be evaluated in x265Encoder::setup().

2. I've tried re-encoding some x265 10bit content in avidemux. I'm using main10 Profile, it gets downconverted to 8bit. Is x265 10bit output currently supported ?

The internal pixel format in Avidemux is YV12 (YUV420P with U and V planes swapped), which means that a decoded picture with 10bit color depth can never reach an encoder.

Finally, I typically don't use a case fan on my dual-core and I would like to limit the encoding to 3 threads to avoid overheating (I  only ever encode short clips and I monitor temperature so this works fine). In avidemux prefs I've set encoding priority to low

Encoding priority has nothing to do with multithreading or limiting CPU load.

and lav threads to 3,

libavcodec decoder multithreading is always disabled in Avidemux, corresponding settings have no effect.

and x265 Frame threads to 1, but I'm still seeing cpu use go up above 95%.

> 95% per core? Or cumulative? (Usually 100% on dual-core means 50% of total, else it would be 200%, for each core at 100% of load)

Is there anything more I can do in avidemux ?

I fear, no.

[butterw]

1. In this thread, it was recommended to encode x265 with open-gop=0 command line option to avoid cutting issues
https://avidemux.org/smif/index.php/topic,19141.0.html
Is it possible to encode in avidemux with parameters not available in the avidemux x265 gui ?

All usable parameters are members of the x265_settings struct.
It doesn't matter whether they are exposed via UI but they must be evaluated in x265Encoder::setup().

So is it possible/needed to set the open-gop parameter in avidemux ?
In ADM_x265, we have: (PI(bOpenGOP); but no corresponding MKPARAM and nothing either in x265_settings.h or the codec .json configuration.

Encoding priority has nothing to do with multithreading or limiting CPU load.

The avidemux process is set to low priority and thus the computer can still be used during near maxed out encoding (>95% of total cpu): this works fine. But ideally I would like to limit encoding at no more than 75% of total. Sticking with x264 looks like a better choice for my recodes.

[eumagga0x2a]

So is it possible/needed to set the open-gop parameter in avidemux ?
In ADM_x265, we have: (PI(bOpenGOP); but no corresponding MKPARAM and nothing either in x265_settings.h or the codec .json configuration.

Should be fixed by [x265] Allow to disable open GOP, thank you for raising the topic.

Sticking with x264 looks like a better choice for my recodes.

I would recommend to look primarily at HW decoding capabilities of your target equipment. If it is capable of decoding HEVC in hardware and you don't need to take into account compatibility with other, older devices, using a far inferior quality-wise H.264 would be IMHO a waste of time and electricity. Else stick with H.264 as HEVC decoding is computationally very expensive.

The real problem is insufficient cooling which should be handled IMHO in hardware, not by throttling the CPU load.

[butterw]

Sticking with x264 looks like a better choice for my recodes.

I would recommend to look primarily at HW decoding capabilities of your target equipment. If it is capable of decoding HEVC in hardware and you don't need to take into account compatibility with other, older devices, using a far inferior quality-wise H.264 would be IMHO a waste of time and electricity. Else stick with H.264 as HEVC decoding is computationally very expensive.

Hardware compatibility with legacy devices is absolutely what makes x264 the better choice for me in 8 bit. I would argue that it is also extremely well optimized and not inferior quality if you throw the extra bitrate at it. Looking forward, I do like x265 for 10bit, but it will have to compete with next-gen codecs (though for individuals, encoding cost seems likely to become just as important as bitrate due to the increase in computational complexity).

The real problem is insufficient cooling which should be handled IMHO in hardware, not by throttling the CPU load.

I was simply reporting that avidemux/x265 encoding hits the cpu harder than most on a 4 thread pc. Some PCs will have worse thermals than mine, but they can still be used for occasional encoding, with a few tricks. By limiting cpu usage (maybe 95% in windows power options in summer) I can permanently avoid the extra fan noise. No problem there.

My actual point was that unless you have a dedicated encoding machine, it doesn't always make sense to encode at maxed-out cpu. My preference is typically to encode in background and be able to use the PC at the same time.
It seems x265.exe has a --pool "x" parameter that can be used to control the number of hyperthreaded cores used. However these modern codecs come with numerous complex parameters and I understand that exposing them in all in a GUI just isn't practical.

Anyway, encoding is not something I use avidemux much for. The key feature for me is easy to use lossless video editing, without re-encoding and most importantly without corrupting the output. Thanks for your efforts.