[FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator

[Ganesh Ajjanagadde]

On Tue, Mar 15, 2016 at 4:37 PM, Derek Buitenhuis
<derek.buitenhuis at gmail.com> wrote:
> On 3/15/2016 10:26 PM, Ganesh Ajjanagadde wrote:
>> If one wants good Gaussian samples, then yes, I need a 64 bit rng.
>> Please also note that I can use av_lfg_get, it does not result in
>> slowdown, since speed benefits here come from the ziggurat algo.
>> Concretely, it is 82 cycles vs 81 cycles; too little to clearly
>> distinguish. I was just not too happy with av_lfg_get << 32 |
>> av_lfg_get as it resulted in some bad values in the Anderson Darling
>> tests.
>
> "If one wants good Gaussian samples" doesn't explain at all how it is
> relevant to a set of multimedia libraries like FFmpeg. Why do we want
> those? That is the relevant information which should be mentioned
> in the commit message.

Preumably as AAC needs them, why else was av_bmg_get added? Anyway,
added a line on this.

>
>> I don't know if good quality Gaussian samples are needed, I welcome
>> comments from AAC coding people.
>
> The impression I have from them (atomnuker in previous email) is that
> it is not that important, but I'm not an 'AAC' person.

Same here. The reason I ask is this: of course all random number
generators are not "truly random". But there are various levels one
can go to:
1. Just use a uniform distribution, who knows, it may "work fine" in
practice. This is the main thing I want answered.
2. Use ad-hoc methods, e.g take a few uniforms, add and normalize, few
being governed by how fast the CLT kicks in and when it starts to
"work fine".
3. Use "reasonably good" Gaussians. I am personally ok with using
av_lfg_get, all I need to do is update the Anderson Darling to a
smaller number of samples.
4. Use "best effort" Gaussians. This needs a 64 bit rng of some sort,
and as such a new function. Whether it becomes public or private is a
detail.

>
>> In particular, I have already mentioned in the patch notes that this
>> yields ~ 1-2% in aac encoding speed. If you do a profile run,
>> av_bmg_get does show up with nearly 2-3% time spent in it overall.
>
> There is no mention of AAC in the patch notes for this patch, actually.

Not for this, but taken as a whole set, it is clear what the general trend was:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191538.html.
Anyway, have reworded slightly.

>
> I'll defer to Rostislav (atomnuker) and other on whether adding yet another
> public API that Is Not Multimedia Related is worth 1-2% yield.

That is a simple matter of details, if you don't want it public, we
can keep it internal until someone wishes to export it. Anyway the
command line utilities and users do not need it.

>
> - Derek
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel