On Wed, Jan 03, 2024 at 07:36:00PM +0100, Michael Koch wrote:
> Possible better algorithm for the random generator, which might fix the
> problem:
>
> eval.c line 235
>
> if (r == 0)
> r = UINT64_MAX/13;
> else
> r = r*1664525+1013904223;
This modifies the properties of the PRNG as it doesn
Possible better algorithm for the random generator, which might fix the
problem:
eval.c line 235
if (r == 0)
r = UINT64_MAX/13;
else
r = r*1664525+1013904223;
Michael
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
On one hand, it's good that the 10 variables for ld() and st() are
initialized with zero.
But on the other hand, zero is obviously the worst possible seed value
for the random generator.
For example, make a 1000x1000 image with red color, and then fill one
pixel at a random position with yello
On date Wednesday 2024-01-03 12:20:12 +0100, Michael Koch wrote:
> > Possible address trac issue:
>
> > http://trac.ffmpeg.org/ticket/10763
>
> I don't like the random generator as it is, because the first two random
> numbers
> are very close to zero, as can be shown with this command line:
>
> Possible address trac issue:
http://trac.ffmpeg.org/ticket/10763
I don't like the random generator as it is, because the first two random numbers
are very close to zero, as can be shown with this command line:
ffmpeg -loglevel repeat -f lavfi -i nullsrc=size=1x1,format=gray -vf
"geq=lum='pr
Possible address trac issue:
http://trac.ffmpeg.org/ticket/10763
---
doc/utils.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/utils.texi b/doc/utils.texi
index ac9b63826e..554a07f057 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -944,11 +944,17 @@ Return a pseudo random v
