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

[Michael Niedermayer]

Hi

On Sat, Aug 04, 2018 at 01:17:53AM +0300, Sergey Lavrushkin wrote:
> 2018-08-04 0:11 GMT+03:00 Michael Niedermayer <michael at niedermayer.cc>:
> 
> > On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote:
> > > 2018-08-03 16:07 GMT+03:00 Michael Niedermayer <michael at 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)
> >
> 
> Well, I want to implement simpler approach, as I still have to finish
> correcting sr filter.
> But I need some explanations regarding what I should add. If I understand
> correcly,

> I need to add conversion from float to the ff_sws_init_input_funcs function
> in libswscale/input.c
> and conversion to float to the ff_sws_init_output_funcs function in
> libswscale/output.c
> If I am not mistaken, in the first case I need to provide c->lumToYV12 and
> in the second case -
> yuv2plane1 and yuv2planeX.

yes that sounds correct


> So, in the first case, to what format should I
> add
> conversion, specifically what number of bits per pixel should be used? As I
> look through other
> conversion functions, it seems that somewhere uint8 is used and somewhere -
> uint16.

you should try to maintain as many bits as possible, so a path similar to
what 16bit formats use would be best


> Is it somehow determined later during scaling? If I am going to convert to
> uint8 from
> my float format, should I define it somewhere, that I am converting to
> uint8?
> And in the second case, I don't completely understand, what these two
> functions are
> doing, especially tha last one with filters. Is it also just simple
> conversions or
> these functions also cover something else? And in their descriptions it is
> written, that:
> 
>  * @param src     scaled source data, 15 bits for 8-10-bit output,
>  *                19 bits for 16-bit output (in int32_t)
>  * @param dest    pointer to the output plane. For >8-bit
>  *                output, this is in uint16_t

also see doc/swscale.txt
note this text is IIRC older than the current swscale code so it
may be missing some things but the general architecture should be correct

also if you notice any errors or omissions in the documentation then
patches improving it are certainly welcome!


> 
> In my case, the output is 32-bit. Does this mean, that float type,
> basically, is not
> supported and I also have to modify something in scaling? If so, what
> should I add?

when input gets converted to the internal integer format and that gets
convverted back to floats at output then scaling should be fine as it
wouldnt "know" there are floats outside

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180804/49f8b144/attachment.sig>