A real world stress test - 4k h.265 encoding
This guide is a help to create a easy to reproduce, real world stress on the CPU with the workload of encoding a h.265 video file. You only need 2 executables and a batch/cmd line for this.
The purpose of this is to have a simple way to simulate the taxing workload that occurs during a video encode, and without the need of having a huge source file on your HDD.
On my own render rig (R7 1700@3.85ghz~1.3v) the tool Prime95 29.1 with "Small FFTs" creates a power consumption of ~254 Watt (from the wall).
During the encoding of a video file, the rig pulls about ~245 Watt. So this workload is very close to the so-called "unrealistic" Prime95 strain.
This stress test is simply a single command line. It pipes FFMPEG and x265 together to encode a virtual video file in memory. The big advantage of this method is, that there is no need to have a source video file, which is usually many gigabytes in size, and also there is no video file to be written to the disc. All is done in RAM. Though, you need a minimum of free RAM for this to work, see list below.
If you have access to ffmpeg.exe and x265.exe on your PC, then simply copy both files into one folder and execute this command line:
ffmpeg -f lavfi -i nullsrc=s=4096x2160 -r 25 -filter_complex "geq=random(1)*255:128:128" -t 6 -strict -1 -pix_fmt yuv420p10le -vsync 0 -f yuv4mpegpipe - | x265 --input - --y4m --output-depth=10 --profile=main10 --preset placebo --tune fastdecode --crf 27 -o NUL
Note:
- The "-t" value changes the total run time of the stress test. It determines the length of the virtual video in seconds. But please keep in mind that this also changes the minimum needed RAM. (see table below)
- When you start the script, FFMPEG is first creating the video in memory (prebuild time), which takes time until it is finished. After that, x265 is encoding the video on full CPU load.
- Sometimes the mouse pointer and system freezes for a minute. This does not mean that your PC has crashed! Just let the computer running and it will recover after a while. The PC does still do its work, but the system just becomes unresponsive for a short time. The best way to detect this "soft-crash", is to use a power meter, as during this freeze, the power consumption is still at maximum. In case that your system crashes, the CPU goes to save mode and the power consumption is way lower than during a stress test. e.g. ~153 Watt, on my rig. In case of a hard-crash the fans should also start to run slower than under full load, so you can hear it too. At least on my motherboard. Another way to detect these soft crashes is to simply play a audio file or video in the background. The encoding priority is low, so that it should not break any playback during this freezes.
I found out that an unstable OC usually crashes after 5-30 minutes. Everything above is dependant on environmental changes, like ambient temperature or simultaneous PC usage for other task, that will lead to a higher chance to crash the PC. If you want to be sure, then use a "-t" value that takes you PC to encode for about 1-2 hours
You can end the this encoding task at any time a with CTRL+C or closing the window.
You can get the executables from these sources:
- x265.exe - https://www.videohelp.com/software/x265-Encoder
- ffmpeg.exe - https://ffmpeg.zeranoe.com/builds
I also have uploaded a zip file with everything included (batch file and executables):
DOWNLOAD
--------------------------------
Table for the runtime: [WIP]
(CPU: R7 1700@3.85ghz - 3200CL14)
| [setting] | [prebuild time] | [ram usage] | [runtime] |
|---|---|---|---|
| t1 | 20-50sec | ~2,0-2,3gb |
392s, 6:31min 0,06fps
|
t2
|
50-100sec | ~3,4-3,6gb |
812s ,13:31min 0,06fps
|
t4
|
60-120sec | ~5,5-5,8gb |
