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 3E82149424
for <ffmpegdev@gitmailbox.com>; Mon, 24 Mar 2025 12:31:28 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E8DCE687B45;
Mon, 24 Mar 2025 14:31:24 +0200 (EET)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net
[217.70.183.197])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7ADAA6879DB
for <ffmpeg-devel@ffmpeg.org>; Mon, 24 Mar 2025 14:31:17 +0200 (EET)
Received: by mail.gandi.net (Postfix) with ESMTPSA id 919D7442F7
for <ffmpeg-devel@ffmpeg.org>; Mon, 24 Mar 2025 12:31:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc;
s=gm1; t=1742819476;
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=2gEEsS5qTHNs13ByV5ZHpl3tPscZ0/0p7qJyHPelPIo=;
b=EkXyCe7b2A5IdHqn5T0pwji/BuMPgAODa+MQYKtqiMuY6phrroI+VtdFie0k4d4VlCHdZN
ggWnu3LybF6d5xOkFsu+ImNCVQY1nuaSAFw8PByaZ406ndppD3cD1I8fElIGm0ipct7Fw4
5O7HS2vgOuqhq3+uxQQ6FOf2YAsL/hm7kwnmxmR1/BslquyS7DFl4aJNTVAvzeRTyUKhcd
CAgV9pWh9ilhkYIeHkpqP1s7QfXLSMBH23/W0OYFzP5fo9y0zQL/oe7abLSO/ZYatYdIP9
XPF5wuRNMn5sW2hfFF9MyL62OjjxKP3RF76GYmPapoH9Daln350/Xhm3x84laQ==
Date: Mon, 24 Mar 2025 13:31:15 +0100
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Message-ID: <20250324123115.GQ4991@pb2>
References: <20250320223028.3469435-1-michael@niedermayer.cc>
<5f802aaa-958b-49c3-9b4e-3b36e97b244c@lynne.ee>
<20250321201349.GF4991@pb2> <20250321211250.GG4991@pb2>
<20250321213658.GH4991@pb2> <20250321222245.GI4991@pb2>
<20250322174520.GN4991@pb2>
<5b9a3c4b-1b77-413f-9f7b-cd6c33bea02e@mediaarea.net>
<20250324015327.GO4991@pb2>
MIME-Version: 1.0
In-Reply-To: <20250324015327.GO4991@pb2>
X-GND-State: clean
X-GND-Score: -70
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduheeljeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpedutedvhfduuedugedufefghefhvedvgffgffekhfdvgfdvtefftdejkeehteefheenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg
X-GND-Sasl: michael@niedermayer.cc
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Implement 2D RLE for remap
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="===============6136608376171959630=="
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250324123115.GQ4991@pb2/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>
--===============6136608376171959630==
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="s1400e1gTJllvIuk"
Content-Disposition: inline
--s1400e1gTJllvIuk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi
On Mon, Mar 24, 2025 at 02:53:27AM +0100, Michael Niedermayer wrote:
> Hi Jerome
>=20
> On Sat, Mar 22, 2025 at 06:54:25PM +0100, Jerome Martinez wrote:
> > Le 22/03/2025 =E0 18:45, Michael Niedermayer a =E9crit=A0:
> > > [...]
> > > Also I failed to find any worthy gain from adjusting mul_count so
> > > while the code in the encoder looks complex ATM alot of that can be
> > > dropped later if for example we choose to never put mul_count > 1 into
> > > the specification and ATM it makes no sense to put that in as theres =
no
> > > significant gain with the material i tested
> >=20
> > I would prefer we don't put mul_count > 1 related code in FFmpeg, even =
if it
> > is still experimental, without a use case demonstrating that this is us=
eful.
>=20
> Ok, ive done some more tests
>=20
> mul_count>1 is for fixed point in float and decimal mantisse*exponent
> formats. This is also what the paper concentrated on that ive looked at.
And before people ask about the paper:
its "ALP: Adaptive Lossless floating-Point Compression"
And before people ask, why we are not using it:
1. its about compressing 1D academic data not images, things like
Barometric Pressure (kPa), Temperature (C=B0), Monetary (Stocks), ...
2. its primarly about 64bit double precission floats
3. with 64bit doubles they tested their method against zstd and zstd beats
them 3.1 to 3.0 compression rate wise.
4. now to 32bit floats, which they tested too, and for that they beat zstd
they achieve 28.1bits per float and zstd 29.7bit/float, all other varian=
ts
they compare against are above 33.4bits per float.
So how do we compare to zstd?
Using ACES_OT_VWG run through -vf tonemap=3Dhable,format=3Dgbrp16 -pix_fmt =
gbrpf32
(to have some sort of simulation of 16bit fixed point sensor data in 32 bit=
float)
and using 256 slices to maximize the effect of the remap tables (the file w=
ith 40
in it uses 40 slices to compare)
rawdump is simply storing the remap tables as raw 32bit floats
rawvideo is rawvideo instead of ffv1
zst is zstd -k -19
noremapstored is simply the ffv1 data without the remap table stored
-rw-r----- 1 michael michael 483868924 M=E4r 24 13:24 float-303503-fixed-4=
0-noremapstored.nut
-rw-r----- 1 michael michael 491567660 M=E4r 24 01:14 float-303503-fixed-2=
56-noremapstored.nut.zst
-rw-r----- 1 michael michael 491835695 M=E4r 24 01:14 float-303503-fixed-2=
56-noremapstored.nut
-rw-r----- 1 michael michael 499059484 M=E4r 24 12:52 float-303503-fixed-4=
0.nut
-rw-r----- 1 michael michael 545695302 M=E4r 24 01:13 float-303503-fixed-2=
56.nut
-rw-r----- 1 michael michael 600666368 M=E4r 24 12:26 float-303503-fixed-2=
56-rawdump2.nut.zst
-rw-r----- 1 michael michael 807719501 M=E4r 24 12:54 float-303503-fixed-r=
awvideo.nut.zst
-rw-r----- 1 michael michael 1085998190 M=E4r 24 12:26 float-303503-fixed-2=
56-rawdump2.nut
-rw-r----- 1 michael michael 1990659135 M=E4r 24 12:54 float-303503-fixed-r=
awvideo.nut
=46rom this you can see, that for this example (assuming i made no mistake)
1. our code to store remap tables needs about half the space that zstd needs
2. ffv1 needs only 60% the space zstd of rawvideo needs
3. the remap tables are 3% of the file with big slices but over 10% with sm=
all
thx
[...]
--=20
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
--s1400e1gTJllvIuk
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ+FQkAAKCRBhHseHBAsP
q9olAJ46VPqRlnMlMsiNgNScBkZ7Ne3PbQCfeonbOjQSs9jsJKedymb7D+UpiNg=
=oU8F
-----END PGP SIGNATURE-----
--s1400e1gTJllvIuk--
--===============6136608376171959630==
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".
--===============6136608376171959630==--