[Ffmpeg-devel] [PATCH] Apple Video Encoder (rpza)
Rich Felker
dalias
Thu Jun 9 01:11:25 CEST 2005
On Wed, Jun 08, 2005 at 04:10:50PM -0400, Dave Dodge wrote:
> On Mon, Jun 06, 2005 at 11:04:27AM -0600, Mike Melanson wrote:
> > Even when using the same random seeds, I am not sure if the ANSI
> > C spec requires the actual random number generator to be implemented the
> > same way on different platforms.
>
> The C standard requires a given implementation to produce the same
> sequence of pseudorandom numbers each time it is seeded with the same
> value. The default seed is 1. There's no guarantee that you'll get
> the same sequence on two different implementations, and it could
> probably be argued that the standard doesn't guarantee that a given
> implementation will produce the same sequence on two separate runs of
> the same program.
>
> > I looked at the way random() is used in the video encoder:
>
> The random() function isn't part of standard C in any case. It's a
> POSIX/UNIX extension. All that ANSI gives you is rand() and srand().
>
> If you need consistent pseudorandom values between implementations,
> options include:
>
> - I think the UNIX nrand48 function makes some guarantees about the
> exact algorithm it uses, and it allows you to provide your own
> state data rather than using a global state.
>
> - You can implement your own. The C standard provides a very simple
> implementation of rand and srand as an example.
>
> - There are several strong random number generators available as open
> source, with Mersenne-Twister and ISAAC probably being the most
> well-known. At least for MT, the example implementation does use
> a global state but can be easily patched to encapsulate all of
> that into a structure and allow you to generate several independent
> streams of data at once.
All this is good info, but aside from the point, which is that random
numbers ARE NOT USEFUL for a video codec lib. Any attempt to use them
is misguided, regardless of whether they're deterministic or corrupt
the calling program's state...
Rich
More information about the ffmpeg-devel
mailing list