From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 202C04CBD3 for ; Tue, 11 Feb 2025 23:49:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D5B6E68BE12; Wed, 12 Feb 2025 01:49:51 +0200 (EET) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1ABA268B5C8 for ; Wed, 12 Feb 2025 01:49:46 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 697084316C for ; Tue, 11 Feb 2025 23:49:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1739317785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lE4+e+tJP2Vspz/OI4M7Un8GF684V6coHjfpPrsWN2A=; b=S9WD6XSV/kugPCYycroDoatp19/30lOUjE/Iu2ciaJjdhC65raVfzwZxT+FQJsjG2oggbJ dGO86sCp7Frlcwobh4LJhVo8AouFcERx/umZBNMVhPoNZYMNv/RlHbCjmaH9JsnY/uNMAf CYE1p9QJq8jyTcPt1so8B3nxiIwqzBVGsDPXYpQU+hUl5Io2/MVduU6A6jJUUto2CfeA7h m1pafPoVfWiqDCHprZ9SAGu79bd415rzWSkDe/0SZobFnuNG0mbHCS+WLNTik0g6J7ixZl LqrfhFAwImpe7kH6b3qWa687hGLyDu5kU0cHv/vg6vsCFcGfhAS6Xn+UskSdaA== Date: Wed, 12 Feb 2025 00:49:44 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20250211234944.GJ4991@pb2> References: <20250205221813.4110398-1-martin@martin.st> <20250205221813.4110398-2-martin@martin.st> <20250206001638.GI4991@pb2> <20250206160443.GT4991@pb2> <317e9c7e-bc5-81dc-f036-9b1426a95b1@martin.st> <20250209222850.GB4991@pb2> <2ddaa6c8-711e-e23c-8d3b-673d2042bf79@martin.st> MIME-Version: 1.0 In-Reply-To: <2ddaa6c8-711e-e23c-8d3b-673d2042bf79@martin.st> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdegvdefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlfedtmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddtudenucfhrhhomhepofhitghhrggvlhcupfhivgguvghrmhgrhigvrhcuoehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgeqnecuggftrfgrthhtvghrnhepudetvdfhudeuudegudefgfehhfevvdfggfffkefhvdfgvdetffdtjeekheetfeehnecukfhppeeguddrieeirdeijedruddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeguddrieeirdeijedruddufedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtpdhnsggprhgtphhtthhopedupdhrtghpthhtohepfhhfmhhpvghgqdguvghvvghlsehffhhmphgvghdrohhrgh X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH v2 2/2] random_seed: Improve behaviour with small timer increments with high precision timers X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============0827709028766131996==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0827709028766131996== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ooXTvI+jn/kkmZpM" Content-Disposition: inline --ooXTvI+jn/kkmZpM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2025 at 03:54:51PM +0200, Martin Storsj=F6 wrote: > On Sun, 9 Feb 2025, Michael Niedermayer wrote: >=20 > > Hi Martin > >=20 > > On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsj=F6 wrote: > > > On Thu, 6 Feb 2025, Michael Niedermayer wrote: > > >=20 > > > > On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsj=F6 wrote: > > > > > On Thu, 6 Feb 2025, Michael Niedermayer wrote: > > > > >=20 > > > > > > > + // If the timer resolution is high, and we get t= he same timer > > > > > > > + // value multiple times, use variances in the nu= mber of repeats > > > > > > > + // of each timer value as entropy. If the number= of repeats changed, > > > > > > > + // proceed to the next index. > > > > > >=20 > > > > > > Does it still work if you check against the last 2 ? > > > > > > or does this become too slow ? > > > > > > What iam thinking of is this > > > > > >=20 > > > > > > 7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,7,8,7,8,8,... and a 9 or 6 or fur= ther distant would trigger it > > > > > >=20 > > > > > > I assume both the CPU clock and the wall time are quite preciss= e so if we > > > > > > just compare them the entropy could be low even with 2 alternat= ing values > > > > >=20 > > > > > Yes, that still works for making it terminate in a reasonable amo= unt of > > > > > time. I updated the patch to keep track of 3 numbers of repeats, = and we > > > > > consider that we got valid entropy once the new number of repeats= is > > > > > different from the last two. > > > > >=20 > > > > > So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of t= he last > > > > > one, we have old repeats 8 and 8, and the new repeat count 7, whi= ch in that > > > > > context looks unique. > > > >=20 > > > > I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used > > > > values not 8,8 > > >=20 > > > Sure, that's probably doable too. > > >=20 > > > > that is, something like: > > > >=20 > > > > if (old2 =3D=3D new) { > > > > FFSWAP(old,old2); > > >=20 > > > I don't see why we'd need to check this if clause at all, it seems to= me > > > that it's enough to have the "if (old !=3D new)" case. > >=20 > > > If we have old2 =3D=3D new, > > > we'd just end up with old2 =3D old, and old =3D (previous old2 value)= anyway. > >=20 > > It was intended to be a least recent used check with 2 entries > >=20 > > If we have a clock running and sample that in precise intervalls > > lets say the clock runs at 1.9hz and we sample at 10hz we would get > >=20 > > clock: 0 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3= 3 4 4 4 4 4 5 5 5 5 5 6 6 6 6 6 7 7 7 7 7 7 8 8 8= 8 8 9 9 > > difference: 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0= 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 1 0 0= 0 0 1 0 > >=20 > > Above adds no entropy after the initial entropy, this can be read forev= er > > it will not improve randomness > >=20 > > here we have runs of repeated clock reads of 5,4,4,5,4,4,4,5,4 > > again we can read this as long as we want there is no entropy gained > > so after a 5,4,4,4 if a 5 happens thats not breaking the pattern and sh= ould > > not be counted as new entropy (if possible) >=20 > Yes, I get that intent. >=20 > It's just that your suggested pseudocode seems unnecessarily complex, or = I'm > missing something: >=20 > if (old2 =3D=3D new) { > FFSWAP(old,old2); > } else if (old !=3D new) { > old2 =3D old; > old =3D new; > } >=20 > If we have the sequence "5, 4, 4, 4, 4", followed by another "5", we have > old2 =3D=3D 5, old =3D=3D 4, new =3D=3D 5. Then we get the same end resul= t (old2 =3D=3D 4, > old =3D=3D 5) both if we execute the code you suggest above, and if we ju= st > execute this: >=20 > if (old !=3D new) { > old2 =3D old; > old =3D new; > } >=20 > Or is there something I'm missing? I don't see the need for the FFSWAP ca= se. >=20 > As long as we check (new !=3D old && new !=3D old2) we should pick up act= ual > deviation from the steady state but not the variance between two values. Heres an example where the SWAP is needed: noswap swap 5 -> [x 5] [x 5] 4 -> [5 4] [5 4] 5 -> [5 4] [4 5] 6 -> [4 6] [5 6] 5 -> [6 5] [6 5] In the last case the 5 is in the old* when the swap was used but not when it was not used thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn --ooXTvI+jn/kkmZpM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ6viFQAKCRBhHseHBAsP qyfIAJ9xzDY5YjLQP6R7HubYYeQTajDWEQCeOV89RR9iYopHhTgeETwE/jBOzoA= =R3s/ -----END PGP SIGNATURE----- --ooXTvI+jn/kkmZpM-- --===============0827709028766131996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============0827709028766131996==--