> > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel