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 0E4CD4CC3F for ; Wed, 12 Feb 2025 09:25:18 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5F21368BEDE; Wed, 12 Feb 2025 11:25:14 +0200 (EET) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6308D68BD1A for ; Wed, 12 Feb 2025 11:25:07 +0200 (EET) Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-30797730cbdso63926381fa.3 for ; Wed, 12 Feb 2025 01:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=martin-st.20230601.gappssmtp.com; s=20230601; t=1739352306; x=1739957106; darn=ffmpeg.org; h=mime-version:references:message-id:in-reply-to:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=S3VmjcC5Q6oQMZj85fsy2alWlh3sjyXjdeyGUMR2kXE=; b=Xe/wuIeWGwc3ERi0ksAjYavCbMQfpvZHPpfKUoK/hO3Dy5NmmRIBDOjBfRUigC0L7y v203j9Ms9dcNsWXuRKilHYs3RgDwRHvlUM48c6R+tqF9x1557hYIZBG5aO/Soq13ki9W QNgPHcjMoYafH4j/2SSYy4hF0CIif+f79wUfM5CtgeOND4ZDfzz1vCFhM+WXHl9R2cOH HiMnjewqGnIw9ni3YoKK6TTuXDyjQw5Tcvp/DO76/AGA1u05eO8RFpeKAkQ7F7+qgFLp x47KsUnyd09fvvoBbOg6TwGDeOtBiC9oE90eYERk+1QGn+TNZLdBoPo+wGcF/6+AMmfB Fh7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739352306; x=1739957106; h=mime-version:references:message-id:in-reply-to:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=S3VmjcC5Q6oQMZj85fsy2alWlh3sjyXjdeyGUMR2kXE=; b=CMCAlAP7Ej56hqGTZkC95bqEL8l3yezu2caj8gkdJuva1tuUMUh/66McVTQCHtAUtr 5UvV/lMEPV2I/YVy2qckwvSGW5FZvrb+wn7Fcn3lz4yeCP+4KSfh/FKqQTbpIcX0n+ZW jC2YeNzo0Sg4BZqOOaB2a/qv0mNz/44eVMRbjRwjp5c5oq7xjq1ZlIJMPVeiCBdeQpw+ nnrytMj1MCT0c9vt7o15tLfChdF9BS3tq1f6RjOEz987FregbK1Syklb9h80RTg3wbcv kumWrSrQDQJYEUbfM3a58tO2bBqXuh+xvpfhgcXMMWISbETdvgmGe2EwKoF9Ro1vwXBg 3YMw== X-Gm-Message-State: AOJu0Yw1j9bOtjziS7P4ARL70gQP89XumDgEsaQpB90b/BS3l8pGHsER OCojQgnKaSEGHIBOgO7ADDXybbI+eWV1ePNBd49UCIY6+0JM2jWbNUCHhgLrdSpLSoPrfZXMSFq i2Q== X-Gm-Gg: ASbGncultsBWfkU80NzYEgAumWDUJenrcY1iYG8922x6xK/iw7i+CgtqYVu1VMiPLsa 2sK2tN62fdriU3HR5sBiPsE9hGOAoC4Yg5zgvU4S1jde6AKaRqe0/X0oNsTNN8gzW6bzKb11t+p 1MdNCAkYQsaS4YICCr1PCd76kO/ODK51uTgROiMTKi4jFZb64bPfoGJ0/jPuvr8eX7V3x61FAbH pi+Nn4heSi7xKBENRRj7GDe8mlLzflI6zt3pSeQoL6nU45w22cIpaxbqyMF/VkS8bUWF3PVgQef LoAgYbo+Jsb9bs/ThJ+aCeMUSq/3L42MQADwNb/1+1NTedL9dOXXtNLw1TbDjJjDJLD9UEVkewp IIut8VNTKWNw= X-Google-Smtp-Source: AGHT+IFMx4FDGhoQxU2Y+Wq7lLZiWb51GcBk2/Xwt3PnLcB1Vi4Pd5JMjlmnFino+HkzLaCWPSJFsQ== X-Received: by 2002:a2e:bc18:0:b0:308:f4cc:951b with SMTP id 38308e7fff4ca-3090373a8f8mr8201621fa.23.1739352305719; Wed, 12 Feb 2025 01:25:05 -0800 (PST) Received: from tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net (tunnel335574-pt.tunnel.tserv24.sto1.ipv6.he.net. [2001:470:27:11::2]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-308ec5467d4sm9633071fa.12.2025.02.12.01.25.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 01:25:05 -0800 (PST) Date: Wed, 12 Feb 2025 11:25:03 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20250211234944.GJ4991@pb2> Message-ID: <9cfa4774-50b1-7f98-4f8-e17ad8793dfb@martin.st> 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> <20250211234944.GJ4991@pb2> MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, 12 Feb 2025, Michael Niedermayer wrote: > On Mon, Feb 10, 2025 at 03:54:51PM +0200, Martin Storsj=F6 wrote: >> On Sun, 9 Feb 2025, Michael Niedermayer wrote: >> >>> Hi Martin >>> >>> On Fri, Feb 07, 2025 at 12:04:53AM +0200, Martin Storsj=F6 wrote: >>>> On Thu, 6 Feb 2025, Michael Niedermayer wrote: >>>> >>>>> On Thu, Feb 06, 2025 at 02:38:48PM +0200, Martin Storsj=F6 wrote: >>>>>> On Thu, 6 Feb 2025, Michael Niedermayer wrote: >>>>>> >>>>>>>> + // If the timer resolution is high, and we get the sa= me timer >>>>>>>> + // value multiple times, use variances in the number = of repeats >>>>>>>> + // of each timer value as entropy. If the number of r= epeats changed, >>>>>>>> + // proceed to the next index. >>>>>>> >>>>>>> Does it still work if you check against the last 2 ? >>>>>>> or does this become too slow ? >>>>>>> What iam thinking of is this >>>>>>> >>>>>>> 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 further= distant would trigger it >>>>>>> >>>>>>> I assume both the CPU clock and the wall time are quite precisse so= if we >>>>>>> just compare them the entropy could be low even with 2 alternating = values >>>>>> >>>>>> Yes, that still works for making it terminate in a reasonable amount= 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. >>>>>> >>>>>> So in the sequence above, e.g. for 7,8,7,8,8,7, at the point of the = last >>>>>> one, we have old repeats 8 and 8, and the new repeat count 7, which = in that >>>>>> context looks unique. >>>>> >>>>> I was thinking that in 7,8,8 that 7 and 8 be the 2 least recent used >>>>> values not 8,8 >>>> >>>> Sure, that's probably doable too. >>>> >>>>> that is, something like: >>>>> >>>>> if (old2 =3D=3D new) { >>>>> FFSWAP(old,old2); >>>> >>>> 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. >>> >>>> If we have old2 =3D=3D new, >>>> we'd just end up with old2 =3D old, and old =3D (previous old2 value) = anyway. >>> >>> It was intended to be a least recent used check with 2 entries >>> >>> 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 >>> >>> 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 >>> >>> Above adds no entropy after the initial entropy, this can be read forev= er >>> it will not improve randomness >>> >>> 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) >> >> Yes, I get that intent. >> >> It's just that your suggested pseudocode seems unnecessarily complex, or= I'm >> missing something: >> >> if (old2 =3D=3D new) { >> FFSWAP(old,old2); >> } else if (old !=3D new) { >> old2 =3D old; >> old =3D new; >> } >> >> 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 resu= lt (old2 =3D=3D 4, >> old =3D=3D 5) both if we execute the code you suggest above, and if we j= ust >> execute this: >> >> if (old !=3D new) { >> old2 =3D old; >> old =3D new; >> } >> >> Or is there something I'm missing? I don't see the need for the FFSWAP c= ase. >> >> As long as we check (new !=3D old && new !=3D old2) we should pick up ac= tual >> 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 Sorry, but your examples do not make sense or do not contain enough = context (it does not include the initial states of the two old values, and = it requires guesswork which ones of the two [x y] values is old and which = one is old2). But to be clear: Please specify the initial values of the variables new, old and old2, for = a case where >> if (old2 =3D=3D new) { >> FFSWAP(old,old2); >> } else if (old !=3D new) { >> old2 =3D old; >> old =3D new; >> } produces a different end result than >> if (old !=3D new) { >> old2 =3D old; >> old =3D new; >> } I claim that for any values of these variables, the end result is the = same. In any case, I'll send an update of the whole patchset - please do review = it; I believe that it works as you want it to, and I would like to move = forward with it. // Martin _______________________________________________ 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".