R3S3t9999
commented
1 week ago Hi, thanks for the suggestion but I prefer x265.exe with the default thread pool. On my end (I encode one movie per day), I never had an encode that failed or stopped. I have an i9 13900ks and it's constantly running in the 95-100C without problems and using all the threads is faster for me, not much but still faster. My room temperature is controlled though (23C).
4k HDR to 1080p HDR , slow preset crf 15: --pools 24: encoded 5770 frames in 326.75s (17.66 fps) x265.exe default( 32 threads): encoded 5770 frames in 321.20s (17.96 fps)
Anyway, it's not like the script x265.exe settings are hardcoded, anyone can add any custom cmd within the script but I understand that not everyone know about the --pools function.
I have a suggestion for an addition to the default x265 commands that the script uses. This addition would make the x265 process more efficient and most users would not likely know about this information to do it on their own.
I had been having issues with the script running on my i7-14700k beyond v2.0.0. It would begin the x265 encode on the 8-2-1 workflow and would randomly just stop encoding after a while. I have discovered that this was due to the newer version of x265 included in the tools pack using a bit more processor power and causing my CPU (water-cooled) to overheat. After much research in x265's multi-threading capability, I have found an optimized command-switch for a more efficient and stable run which should work great on all processors. According to x265's help, you should only be using 1 thread per physical core per CPU socket, which according to the help pages, x265 is supposed to do by default. Any more than that will give a near-zero increase in performance but will greatly increase power-use and temperature, even accounting for Hyper-threading.
In my case, my processor has 20 physical cores, but 28 logicals. x265 was running with 28 threads by default. To solve this issue, I have added some code to your script which finds the number of physical cores and assigns that to a variable which can then be called in the x265 command. As the help pages claimed, this did not change my encoding performance by any real measurable difference and my power-use and CPU temps have dropped considerably. This code is below:
This could run at the start of the script then it just needs to add "--pools %physical_cores%" to any x265 command.
This code would need an edit to be compatible with machines with multiple CPUs, however I don't have one to test and fix the code for that purpose sadly. Though that is likely a very small number of your users.