On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote: > 2018-08-03 16:07 GMT+03:00 Michael Niedermayer <mich...@niedermayer.cc>: > > > On Thu, Aug 02, 2018 at 09:52:45PM +0300, Sergey Lavrushkin wrote: > > > This patch adds two floating-point gray formats to use them in sr filter > > for > > > conversion with libswscale. I added conversion from uint gray to float > > and > > > backwards in swscale_unscaled.c, that is enough for sr filter. But for > > > proper format addition, should I add anything else? > > > > > > --- > > > libavutil/pixdesc.c | 22 ++++++++++++++++++ > > > libavutil/pixfmt.h | 5 ++++ > > > libswscale/swscale_internal.h | 7 ++++++ > > > libswscale/swscale_unscaled.c | 54 ++++++++++++++++++++++++++++++ > > +++++++++++-- > > > libswscale/utils.c | 5 +++- > > > > please split this in a patch or libavutil and one for libswscale > > they also need some version.h bump > > > > Ok. > > also fate tests need an update, (make fate) fails otherwise, the update > > should > > be part of the patch that causes the failure otherwise > > > In one test for these formats I get: > > filter-pixfmts-scale > grayf32be grayf32le monob > f01cb0b623357387827902d9d0963435 > > I guess, it is because I only implemented conversion in swscale_unscaled. > What can I do to fix it? Should I implement conversion for scaling or maybe > change something in the test, so it would not check these formats (if it is > possible). > Anyway, I need to know what changes should I do and where.
well, swscale shouldnt really have formats only half supported so for any supported format in and out it should work with any width / height in / out Theres a wide range of possibilities how to implement this. The correct / ideal way is of course to implement a full floating point path for scaling along side the integer code. a simpler aprouch would be to convert from/to float to/from integers and use the existing code. (this of course has the disadvantage of loosing precission) [...] > > + const uint8_t *srcPtr = src[0]; > > > + float *dstPtr = (float *)(dst[0] + dstStride[0] * srcSliceY); > > > + > > > + for (y = 0; y < srcSliceH; ++y){ > > > + for (x = 0; x < c->srcW; ++x){ > > > + dstPtr[x] = (float)srcPtr[x] / 255.0f; > > > > division is slow. This should either be a multiplication with the > > inverse or a LUT with 8bit index changing to float. > > > > The faster of them should be used > > > > LUT seems to be faster. Can I place it in SwsContext and initialize it in > sws_init_context when necessary? yes of course thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel