[x264-devel] Varying of PSNR as a function of thread count

[BugMaster]

On Mon, 20 Apr 2015 11:43:29 +0200, Harald Alvestrand wrote:
> Hello,

> I mentioned earlier that I had observed some relationship between x264
> PSNR and thread count - with higher thread count damaging PSNR.

> I have now run the experiment in a more controlled fashion, and the
> table at the bottom of the message is what I found (third column is
> PSNR, rest is parameters to the configuration tool).

> Example command line used, to give the value of all the other options:

> x264 --bitrate 768 --fps 30 --input-res 832x480 --quiet --threads 50
> --tune psnr -o
> /home/hta/code/compare-codecs/workdir/x264/5ab1c0dda2c1/768/RaceHorses_832x480_30.mkv
> video/mpeg_video/RaceHorses_832x480_30.yuv

> This seems to indicate a negative impact of up to 1.5 dB PSNR between
> 1-thread and 64-thread models, with 1-thread being best. Is this as
> expected?

Yes, some quality hit is expected with increase of threads count and
this is documented in
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=doc/threads.txt;hb=HEAD
Also you worsen result due the use of 1-pass ABR instead of CRF or
2-pass on short video sequence because higher number of threads mean
more frames to buffer before ratecontrol will start adapt to your
target bitrate (less frames to adapt).

> (I also observed that the measured CPU time with --threads 1 on my
> system is 6.7 seconds, while all configurations with multiple threads
> come in above 8.1 seconds, with all configurations above 6 threads
> taking 11 CPU-seconds. Is this also as expected?)

Looks like your time measurements are broken or I didn't understand
what you tried to measure.

> These tests are using x264 checkout dd79a61 dated October 20 2014.

> ...

> Harald

Objective metrics are meaningless if you don't have same bitrate
(real streams bitrate not target bitrate) or at least without
accounting for difference in bitrate.