Re: [FFmpeg-devel] [RFC] FFV1 float support

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3867 bytes --]

Hi

On Thu, Mar 06, 2025 at 03:14:49AM +0100, Lynne wrote:
> On 06/03/2025 01:15, Michael Niedermayer wrote:
> > Hi everyone
> > 
> > Current FFv1 code with my patchset supports 16bit floats. The implementation
> > is quite simple. Which is good
> > 
> > I have tried improving compression, the gains are incremental, but its not
> > large overall. For example 44% space gain on the remapping table is just
> > 0.1% overall.
> > 
> > I have few float samples. Its mainly one high quality slideshow of unrelated
> > 16bit float images. These excercise a wide range fo things including negative
> > color values.
> > I think I have only one single (non slideshow) video of float 16 samples,
> > 
> > It turns out the most efficient way to store floats that i found, is to remap
> > them to integers. Not to store tham as sign, exponent, mantisse, i tried that
> > for many hours.
> > 
> > Storing them using a remapping, has a very nice side effect though, and that is
> > it will be easy to add 32bit and 64bit float support (once there is some
> > sample data)

> > Because a image of 64bit floats, after its split into slices of up to 256x256
> > can always be mapped into 16bit integers within each slice.
> 
> *how*? Unlike ints, you cannot simply shift and extract bits from floats and
> treat them as floats.

well, if the input is IEEE 754 32bit or 64bit floats or some 16bit floats.
they can be read with AV_RL16/32/64 and are then 16/32/64bit ints. So we have
slices of 256x256 or smaller of such integers.
A 256x256 slice has at maximum 64k distinct values, these values can
always be stored in 16bit, once they are remapped to a compact list.

There are no floats after the remapping and before its inverted in the decoder

directly doing anything with floats is not bit exactly defined in C so we
have to work with integers anyway in a lossless codec.


> 
> > What about the mapping itself, it uses a rather simple rle coder. ive spend
> > most of the day today tuning that and failing to really beat that.
> > Using context from the previous image didnt work with the slideshow material
> > i have nor that one video i have. I tried using sign and exponent as context,
> > tried previous run, relations of runs, low bits and many more, but no or
> > insignificant improvments of yesterdays implementation was achieved.
> 
> I did mention this once before, but you should look into the Daala/Opus way
> of storing rawbits into a separate chunk at the end of the bitstream. It
> avoids polluting the range context with equiprobable bits.

This may fit into my LSB work but that is not float specific and its not
needed for float support.

I originally thought we would do floats through RAW storing LSB, and special
handling the "always" 0 and 1 bits. It makes sense but just remapping only
the used values to a compact list eliminates all the constant bits for free
and we never have more than 16bits per sample

We still can implement storing LSB raw, i have written 2 implementations
the first without range coder was this:
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-October/334718.html

I didnt like it, but it seems more popular

Also given the raw bits are a known and constant length. It could make
sense to put them first if they are stored non interleaved.

but IIRC, the implementation for LSB refered in the link decorrelates
after LSB is split, it should give more compression doing it the
other way around.
That said the LSB patch still isnt needed for float support, it could
improve speed at the expense of compression for 16 and 32bit samples (float or other)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".