[FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Martin Vignali]

> > But maybe to make tests simpler, we can use/add bit exact conversion
> > for uint8 to float, we can generate a LUT without float calc
> > and for uint16 to float, we can add a uint16 to float conversion without
> > float calc, or maybe, generate a LUT in bit exact mode (probably faster,
> if
> > it's acceptable to have a LUT for 16bit entries)
>
> I think before you design everything around a non float based convertion
> it would make sense to evaluate the speed of SIMD for the convertion.
> so all the choices are understood
>
>
> >
> > If the bit exact mode is much slower than the "float" version we can keep
> > both,
>
> this is possible, it is not ideal though as the tested and used in practice
> code path differs then. Of course a bit exact version does make sense
> either
> way. As some people probably want scaling to be bitexact
>
>
Having func too much complicated to test, have more chance to make func not
tested at all
Bit exact mode is convenient for testing inside ffmpeg, but also useful
outside, for example to be sure transcoding pipeline still give the same
output (when i can, i prefer to use this even if the conv is slower,
because is more reliable).

Following your comments, i propose
for a first step to add bit_exact mode for float <-> uint8/16 where i can,
keeping the current func (adding a test for SWS_BIT_EXACT, in order to
choose the right func)

In a second step, test simd for "float" version.
If using SIMD (or not), we can have faster conv, using the "float" method,
we keep each func
otherwise we remove the non bit-exact version, and add a comment in the
code.

If we keep both func, we can make a test func by func, comparing bit exact
with non bit-exact, in order to be sure, both way to make the conversion
have similar result.

Martin