From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
	by master.gitmailbox.com (Postfix) with ESMTPS id 4A0F54AB7C
	for <ffmpegdev@gitmailbox.com>; Tue, 25 Mar 2025 01:51:05 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
	by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A8325687B8D;
	Tue, 25 Mar 2025 03:51:01 +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 19FED687A58
 for <ffmpeg-devel@ffmpeg.org>; Tue, 25 Mar 2025 03:50:55 +0200 (EET)
Received: by mail.gandi.net (Postfix) with ESMTPSA id 77DEE440D9
 for <ffmpeg-devel@ffmpeg.org>; Tue, 25 Mar 2025 01:50:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc;
 s=gm1; t=1742867454;
 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=luIMDEebMEfXbtw5yMq5nwaliHyGnn45yZObw8my3Cg=;
 b=EMGNjGk//Gygk5sSs+opRv89+Re9+8bwu1BVTIsFAjDcwHWUk3kvmzD8QM6RHVSnnyVoRL
 ZBeTEws9+cKHC2dqENvsp3qIbdrJyYScd7tn3Ns0xvmmuaDpMo9bozoGsLLhWaMhQetI5s
 HT65TGnCqt+94/1oikxWD0mIMlxYVX49bErdbgdM0vlvjymiSI5kZ1tLhah30+m6WE/Hxl
 ldBrxVTS78GHKSX7exZDp+pFsaLZ7rlleDOPQBSBdPowMJJKSYm27JMxiKD8TbwIPPU/mV
 SJycsx322ZkYLn5wDvj0JauZOqMorEMAuu+6vpkYqgJ0hMsx4jmwjSGCn0A5xg==
Date: Tue, 25 Mar 2025 02:50:53 +0100
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Message-ID: <20250325015053.GU4991@pb2>
References: <20250324222051.19096-1-jamrial@gmail.com>
MIME-Version: 1.0
In-Reply-To: <20250324222051.19096-1-jamrial@gmail.com>
X-GND-State: clean
X-GND-Score: -85
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedufeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdduhedmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpedutedvhfduuedugedufefghefhvedvgffgffekhfdvgfdvtefftdejkeehteefheenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg
X-GND-Sasl: michael@niedermayer.cc
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/ffv1enc: further reduce stack
 usage
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: multipart/mixed; boundary="===============0371177816419230268=="
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250325015053.GU4991@pb2/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>


--===============0371177816419230268==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rjuBwt+IEnT8m26h"
Content-Disposition: inline


--rjuBwt+IEnT8m26h
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

On Mon, Mar 24, 2025 at 07:20:50PM -0300, James Almer wrote:
> Continues from commit 702239bc500b, fixing FATE failures on MacOS.
>=20
> Signed-off-by: James Almer <jamrial@gmail.com>
> ---
> Confirmed by Martin Storsj=F6. Float encoding untested.
>=20
>  libavcodec/ffv1.h    |  16 ++++
>  libavcodec/ffv1enc.c | 177 +++++++++++++++++--------------------------
>  2 files changed, 84 insertions(+), 109 deletions(-)
>=20
> diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
> index 09118e0b7d..d1c239f138 100644
> --- a/libavcodec/ffv1.h
> +++ b/libavcodec/ffv1.h
> @@ -115,6 +115,22 @@ typedef struct FFV1SliceContext {
>          uint32_t val; //this is unneeded if you accept a dereference on =
each access
>          uint16_t ndx;
>      } unit[4][65536];
> +    struct RemapEncoderState {
> +        int delta_stack[65536];     //We need to encode the run value be=
fore the adjustments, this stores the adjustments until we know the length =
of the run
> +        int16_t index_stack[65537]; //only needed with multiple segments
> +        uint8_t state[2][3][32];
> +        int mul[4096+1];
> +        RangeCoder rc;
> +        int lu;
> +        int run;
> +        int64_t last_val;
> +        int compact_index;
> +        int mul_count;
> +        int i;
> +        int pixel_num;
> +        int p;
> +        int current_mul_index;
> +    } remap_state;
>  } FFV1SliceContext;

please provide a link to the failure

This makes the code increasingly ugly.

i dont understand why this breaks fate, fate should not use
any of the float code as none should be run in fate ATM.
its also all under -strict -2 checks

this is temporary data not needed outside float32
and not needed outside the remap table writing.

we may need more than one such state.
(if we dont use a heuristic but actually
 encode bruteforce / trial and error)

t conflicts with all work i did today

theres tons of unused memory.

We ATM do 2 things in encode_float32_remap_segment()
one is encoding the table
the other is writing the remaped pixels into sc->bitmap
by using unit[s.p][s.i].ndx

sc->bitmap is unused before, unit[s.p][s.i].ndx unused afterwards
the input image itself is also not used again
half of fltmap32 is unused (thats 512kb alone here)

the code can be writen so it doesnt need the stack
but just runs twice over the stuff (not sure how clean this
would be but if you try _please_ do it on top of the patches
i posted today, the code is simpler and less buggy after
these patches

But i really dont understand why fate fails in relation to code
it never executes.

thx

[...]
--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

--rjuBwt+IEnT8m26h
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ+IL+gAKCRBhHseHBAsP
q0dlAJ92w3UzbN0qRadyyeO4N7vjvXvJRQCeKGKvu6996xgWG8ZuKDPKYL3hxdY=
=1K7w
-----END PGP SIGNATURE-----

--rjuBwt+IEnT8m26h--

--===============0371177816419230268==
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".

--===============0371177816419230268==--