[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