Why do stats-files differ at exact same setting?

[Jan Marijniszoon]

No matter what I feed x264.exe via MeGui (DirectShowSource, DirectShowSource with GRF-files or FFMpegSource), when I feed it the same source with the exact same settings with the exact same version of x264 it spits out different stats-files at the first pass; even when the Turbo option is disabled.

Now is this a normal situtation? Are the decoders I used not putting out the same signal each time? Is this a bug in x264 (not likely!) or am I just plane stupid and missing out on something here?
Please help!

[Dark Shikari]

x264, in threaded mode, is not necessarily deterministic.

[Jan Marijniszoon]

Haha which means?

Sorry I am not that big of a technician.

I indeed use 2 threads because I have a duo processor.

But in my world I would say: if you put something in a machine then should the output not always be the same?

Why would it produce other information about the same movie only because it is threaded? I don't understand. Could you try and explain it in lamen language please? ;)

[Dark Shikari]

Haha which means?Its not deterministic--that is, if you run it two times, it won't give exactly the same results.

[Jan Marijniszoon]

But this means this affects the second pass too.
Will this be for better of for worse?

[Dark Shikari]

But this means this affects the second pass too.
Will this be for better of for worse?Neither.

[Trahald]

is that practice common in multithreaded environments, ds? just curious ( i dont care since as long as output looks good thats all that matters. )

[Dark Shikari]

is that practice common in multithreaded environments, ds? just curious ( i dont care since as long as output looks good thats all that matters. )Getting multithreading to be exactly deterministic is often difficult--x264 should be but isn't with some combinations of settings due probably to some very subtle and not-very-important bugs.

[IgorC]

I indeed use 2 threads because I have a duo processor.

Maybe 3 threads?
threads = 1.5*cores

[Manao]

Getting multithreading to be exactly deterministic is often difficultHuh ?

Getting the same behavior multithreaded vs monothreaded might be difficult (for example, slice based will give different results with different number of slices), but deterministic behavior is usually easy to get.

And bugs are always important, especially when unexplained.

[Dark Shikari]

Huh ?

Getting the same behavior multithreaded vs monothreaded might be difficult (for example, slice based will give different results with different number of slices), but deterministic behavior is usually easy to get.

And bugs are always important, especially when unexplained.I don't think they're unexplained; I'm pretty sure the nondeterminisms come from RDO and the nonzero count array. However, I haven't seen much benefit (in most cases) from using correct values for these, and often its a nightmare to ensure that the correct ones are being used under subme=7, especially with QPEL RD.

[Gabriel_Bouvigne]

On the other hand, having a deterministic behavior would be very helpful for some debug tasks...