Why the two execution of X264 are different？

[xkfz007]

I am using the following commands to run the X264 under multithreads for MB-TREE algorithm:
./x264 -b 0 --threads 4 --lookahead-threads 1 --rc-lookahead 10 --aq-mode 1 -o test.264 ~/sequences/bus_352x288_25.yuv --fps 25 --frames -1 -I 30 -B 500 --b-adapt 0 --b-pyramid none --ref 5 --weightp 0 --no-scenecut -v --tune psnr --psnr --no-psy --no-asm >a.txt 2>&1

However, each time the result is different. How could that be possible?

[LoRd_MuldeR]

What exactly do you mean with "the result is different"?

File hashes don't match? Files come out at different size? Files actually look different?

Anyway, as far as I remember, x264 is supposed to be deterministic (i.e. always gives the same result for the same input), unless you either specify "--non-deterministic" or use VBV.

So if you think you found a case where x264 is not deterministic, you should probably file a bug report. But, first of all, track down the particular option that causes this!

[kabelbrand]

However, each time the result is different. How could that be possible?
You won't get bit identical results if you use more than one thread.
See here: http://forum.doom9.org/showthread.php?p=956564#post956564

[LoRd_MuldeR]

You won't get bit identical results if you use more than one thread.
See here: http://forum.doom9.org/showthread.php?p=956564#post956564

I don't think that's quite correct. x264 synchronizes the threads in a way that guarantees deterministic results – unless the "--non-deterministic" switch is used.

At least that's how it's supposed to work ;)
--non-deterministic
Slightly improve quality of SMP, at the cost of repeatability

See also:
http://mewiki.project357.com/wiki/X264_Settings#non-deterministic


The major exception here is VBV – which, according to the developers, is inherently non-determinsitc. But he didn't use VBV, so that can't be the reason.

[xkfz007]

The major exception here is VBV – which, according to the developers, is inherently non-determinsitc. But he didn't use VBV, so that can't be the reason.
Yeah, I didn't use the VBV.
I have found the reason.
In my running of X264, multithreads and MB-TREE are enabled. When thread number is larger than 1, two more threads will be created, which are the IOThread and a LookaheadThread. When the IOThread and the MainThread run faster than LookaheadThread, much more frames will be put in the lookahead->ifbuf. So the frame number in lookahead->next will be larger than the number decided in the command line(--rc-lookahead) and this makes the MB-TREE analyse more frames and the QP offsets will be different.
BTW, the default value of b_determinstic in my codes is changed to 0, so the results are different. When the b_determinstic is set to 1, the results are the same.
The results, I mean, the final PSNR values and bitrate.

[MasterNobody]

BTW, the default value of b_determinstic in my codes is changed to 0, so the results are different. When the b_determinstic is set to 1, the results are the same.
Then why are you asking? You specifically asked libx264 to not care about deterministic result (--non-deterministic).

[xkfz007]

Then why are you asking? You specifically asked libx264 to not care about deterministic result (--non-deterministic).

At first, I didn't know it was changed. The x264 source I used is a project transplanted to Windows (a version in 2012) by others. Then through this Post, I realised the variable b_deterministic and found it was changed in the x264_param_default function.

[kabelbrand]

The major exception here is VBV – which, according to the developers, is inherently non-determinsitc. But he didn't use VBV, so that can't be the reason.
You are right, I totally forgot this is VBV related.