Hi, On Tue, Mar 15, 2016 at 10:29 AM, Derek Buitenhuis < derek.buitenh...@gmail.com> wrote:
> On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote: > > Concretely, it is nearly as fast as av_lfg_get (which only returns 32 > bits), > > and has a much smaller cache (128 bits). Thus, the timings should also > > be more stable. > > > > This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and > > likely less random as measured by BigCrush - most LFG's perform > > quite poorly on the BigCrush suite: > > http://www6.tw.freebsd.org/distfiles/testu01.pdf. > > In particular, FFmpeg's seems to be Ran055 in the paper, see pg31. > > This doesn't explain how it benefits our uses of PRNGs. We are a set of > multimedia > libraries, not a general utilities library. Most of our use is for noise > generation > or unit tests, neither of which benefits much/at all from this. For > encrypted streams, > we pass in keys via options (e.g. MP4 CENC), mostly. Might be related to aacenc? But yes, we need to know overall speed gain of some useful end user feature before/after this. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
