Should x264 be non-deterministic when '--non-deterministic' isn't used?

[Selur]

Over at videohelp (https://forum.videohelp.com/threads/399221-MeGUI-x264-Avisynth-encodings-keep-coming-out-at-different-filesizes), there is someone you get's non deterministic output even when he isn't using '--non-deterministic'.

Some folks say that:
a. x264 is always non-deterministic as soon as multithreading is used.
b. x264 is always non-deterministic as soon as VBV is used.
c. x264 is always non-deterministic as soon as VBV&multithreading are used together.
I though that x264 should be deterministic as long as '--non-deterministic' isn't used and if it isn't there is a bug?
Also when a., b. or c. is correct, what is the use of '--non-deterministic' ?

Can someone knowing the code answer this?


Cu Selur

[Asmodian]

I always believed a was true. Since the relative performance between threads is non-deterministic the code would need to wait for unencoded blocks it expected to be complete but I don't believe it does.

Of course, I am not someone knowing the code. :)

[Greenhorn]

According to the x264 mailing list from 2015, vbv+multithreading is intentionally non-deterministic.

https://mailman.videolan.org/pipermail/x264-devel/2015-April/011035.html

[Asmodian]

There isn't much in the way of why there.

Is it only non-deterministic for case c then?

[benwaggoner]

There isn't much in the way of why there.

Is it only non-deterministic for case c then?
Deterministic has a perf hit and doesn't offer any compression efficiency advantage. Non-deterministic really should be the default, with deterministic only used when pixel-exact technical comparisons are being done.

I've done HUGE amounts of x264 tuning over the last 10+ years, and I don't think I've ever had a need to use deterministic mode.

[Selur]

Especially if running witht ou '-non-deterministic' doesn't really make x265 deterministic.

[Asmodian]

Deterministic has a perf hit and doesn't offer any compression efficiency advantage. Non-deterministic really should be the default, with deterministic only used when pixel-exact technical comparisons are being done.

So it is only c. and because a. is not true --non-deterministic should always be used to avoid the issue I mentioned?

I've done HUGE amounts of x264 tuning over the last 10+ years, and I don't think I've ever had a need to use deterministic mode.

I do have --non-deterministic in all my command lines but I am still curious. :)