[FFmpeg-devel] [PATCH] avcodec/ffv1: Implement 2D RLE for remap

Michael Niedermayer michael at niedermayer.cc
Sat Mar 22 19:45:20 EET 2025


On Fri, Mar 21, 2025 at 11:22:45PM +0100, Michael Niedermayer wrote:
> On Fri, Mar 21, 2025 at 10:36:58PM +0100, Michael Niedermayer wrote:
> > On Fri, Mar 21, 2025 at 10:12:50PM +0100, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Fri, Mar 21, 2025 at 09:13:49PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Mar 21, 2025 at 12:07:30AM +0100, Lynne wrote:
> > > > > On 20/03/2025 23:30, Michael Niedermayer wrote:
> > > > > > This performs about as good as the non LRU system for 16bit and
> > > > > > better than then the LRU system for 16 converted to 32. So
> > > > > > its basically performing best in all cases we have atm making
> > > > > > the LRU system unneeded.
> > > > > 
> > > > > Test on *real* 32-bit content, please. You can generate some by using the
> > > > > tonemap filter, or any of the others that support it.
> > > > 
> > > > iam happy to test tonemap output but
> > > > tonemap output is not "real content" either
> > > 
> > > tested the previous LRU code and this with ACES_OT_VWG run through tonemap
> > > this still performs better than the previous LRU code.
> > 
> > heres the test results,
> > the try1 and try256 case try hardcoded mul values of 1 and 256, they
> > perform worse than the automatically selected ones
> > noremapstor simply does not store the remap table and thus shows how big that
> > table is (its quite huge with the tonemap output)
> > the rest shows that the LRU code performs worse in every tested case
> > that gz file is just a sanity check to ensure that we arent writing tons
> > of low entropy data.
> > 
> > -rw-r----- 1 michael michael  694591360 Mar 21 21:57 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-noremapstor.nut
> > -rw-r----- 1 michael michael  916492722 Mar 21 21:54 float-303503-c1-m2-s40-tmf32-nolsb-retrrr.nut.gz
> > -rw-r----- 1 michael michael  917135003 Mar 21 21:54 float-303503-c1-m2-s40-tmf32-nolsb-retrrr.nut
> > -rw-r----- 1 michael michael  921698263 Mar 21 22:03 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try256.nut
> > -rw-r----- 1 michael michael  921725671 Mar 21 22:04 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-tryLRU.nut
> > -rw-r----- 1 michael michael  921729598 Mar 21 22:01 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try1.nut
> > -rw-r----- 1 michael michael  928459175 Mar 21 22:23 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try-linear.nut
> > -rw-r----- 1 michael michael  932903780 Mar 21 22:22 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-tryLRU-linear.nut
> > -rw-r----- 1 michael michael 1100100630 Mar 21 22:24 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try-gamma.nut
> > -rw-r----- 1 michael michael 1101005617 Mar 21 22:22 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-tryLRU-gamma.nut
> > -rw-r----- 1 michael michael 1150326564 Mar 21 22:23 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try-hable.nut
> > -rw-r----- 1 michael michael 1153310394 Mar 21 22:22 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-tryLRU-hable.nut
> 
> and of course my testing had a bug, i set the wrong remap mode
> 
> -rw-r----- 1 michael michael  694591360 Mar 21 21:57 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-noremapstor.nut
> -rw-r----- 1 michael michael  915326963 Mar 21 22:55 float-303503-c1-m3-s40-tmf32-nolsb-retrrr-tryLRU.nut
> -rw-r----- 1 michael michael  917135003 Mar 21 21:54 float-303503-c1-m2-s40-tmf32-nolsb-retrrr.nut
> -rw-r----- 1 michael michael  921698263 Mar 21 22:03 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try256.nut
> -rw-r----- 1 michael michael  921729598 Mar 21 22:01 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try1.nut
> -rw-r----- 1 michael michael  922576142 Mar 21 22:54 float-303503-c1-m3-s40-tmf32-nolsb-retrrr-tryLRU-linear.nut
> -rw-r----- 1 michael michael  928459175 Mar 21 22:23 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try-linear.nut
> -rw-r----- 1 michael michael 1100100630 Mar 21 22:24 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try-gamma.nut
> -rw-r----- 1 michael michael 1114541572 Mar 21 22:52 float-303503-c1-m3-s40-tmf32-nolsb-retrrr-tryLRU-gamma.nut
> -rw-r----- 1 michael michael 1150326564 Mar 21 22:23 float-303503-c1-m2-s40-tmf32-nolsb-retrrr-try-hable.nut
> -rw-r----- 1 michael michael 1157209215 Mar 21 22:52 float-303503-c1-m3-s40-tmf32-nolsb-retrrr-tryLRU-hable.nut
> 
> so for the linear and none tonemaps, LRU is 0.2% and 0.6% better, for the others its worse.
> That said, for the 2D RLE only 1 mul value and only powers of 2 of that is searched.
> 
> That said, we can try other algorithms. My main goal ATM is though to keep
> things simple, ideally 1 simple algorithm.
> Both the LRU/RLE and 2d RLE algorithms are quite simple
> the 2d RLE is very simple on the decoder side and on the encoder side its the
> encoders choice is it wants to optimize the parameters or just treat it like
> a normal RLE
> also the 2d RLE allows us to tune the step (=mul) for the whole range which
> allows storing various lower than 32 bit floating point formats efficiently
> (thats tested and confirmed with that float16 input)
> and we can also store a step per exponent which should allow storing fixed
> point formats efficiently. (thats not tested)
> For true float32 that value is just 1 and its just RLE. (which we confirmed
> to work too now)
> 
> The same remap system can also be used with non float data like 16bit integers
> where the mul value would allow very compact removial of any fixed pattern
> in the LSB while allowing efficient coding of exceptions.
> 
> How much better than this simple way of storing the remap table can we do?
> I dont know, maybe i have a new idea when i wake up tomorrow :)
> but ATM i like it as its simple and seems to work well for its simplicity

Also spend most of the day today working on this more. Ive simplified the
remap decoder code, fixed a bunch of issues in the encoder and tested
my heuristic that chooses the mul value vs brute force of all power of 2
values. Basically brute force is not worth the extra time.
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

The remap encoder code is also more flexible now as it can easily and cleanly
be run several times (to compare effects of parameters)

I do intend to apply my current code for float32 support and the remap
code in the next 24h (with whatever bugfixes it has at the time)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250322/c7fa1cbb/attachment.sig>


More information about the ffmpeg-devel mailing list