Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
> > 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
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Wed, Aug 22, 2018 at 10:20:53AM +0200, Martin Vignali wrote: > > > > > So the only thing I can do is to disable these tests for > > > these formats. > > > Otherwise, I need to test other changes somehow. Here is the patch, that > > > skips > > > pixfmts tests for these formats. > > > > in absence of another solution this should be ok > > > > > I'm not against, removing these tests for now, > > 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 > in order to use the bit exact for various tests > and use it as reference in order to compare bit exact and "float" conv for > each func. > > I can send patch for this, if need. > > Martin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
Martin Vignali wrote: >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) In my experience, a LUT in bit exact mode is indeed faster. To me the proposed addition would be useful. And I guess LUTs for 16-bit entries will become necessary anyway at some point... Thank you! Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
> > > So the only thing I can do is to disable these tests for > > these formats. > > Otherwise, I need to test other changes somehow. Here is the patch, that > > skips > > pixfmts tests for these formats. > > in absence of another solution this should be ok > > I'm not against, removing these tests for now, 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) If the bit exact mode is much slower than the "float" version we can keep both, in order to use the bit exact for various tests and use it as reference in order to compare bit exact and "float" conv for each func. I can send patch for this, if need. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Mon, Aug 20, 2018 at 11:27:05PM +0300, Sergey Lavrushkin wrote: > 2018-08-18 23:20 GMT+03:00 Michael Niedermayer : > > > On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote: > > > 2018-08-17 23:28 GMT+03:00 Michael Niedermayer : > > > > > > > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote: > > > > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > > > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > > > > > >>> > > > > > >>> Just use av_clipf instead of FFMIN/FFMAX. > > > > > >> > > > > > >> > > > > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > > > > > > > > > will apply > > > > > > > > > > > > thanks > > > > > > > > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > > > > > tested for bitexact output. The gbrpf32 ones aren't, for example. > > > > > http://fate.ffmpeg.org/report.cgi?time=20180816131312= > > > > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx > > > > > > > > h > > > > i remember i had tested this locally on 32bit > > > > can something be slightly adjusted (like an offset or factor) to avoid > > any > > > > values becoming close to 0.5 and rounding differently on platforms ? > > > > > > If not the tests should skip float pixel formats or try the nearest > > > > neighbor scaler > > > > > > > > > > Can it really be the problem with scaler? Do all these failed test use > > > scaling? > > > Is not it the problem, that different platforms can give slightly > > different > > > results for > > > floating-point operations? Does input for the float format is somehow > > > generated > > > for these tests, so the input conversion is tested? Maybe it uses output > > > conversion first? > > > If it is the problem of different floating-point operations results on > > > different platforms, > > > > > maybe it is possible to use precomputed LUT for output conversion, so it > > > > I dont think we should change the "algorithm" to achive "bitexactness" > > we could of course but it feels like the wrong reason to make such a > > change. How its done should be choosen based on what is fast (and to a > > lesser extend clean, simple and maintainable) > > > > > > > > > will give > > > the same results? Or is it possible to modify tests for the float format, > > > so it will > > > check if pixels of the result are just close to some reference. > > > > Its possible to compare to a reference, we do this in some other tests, > > but thats surely more work than just disabling teh specific tests or trying > > to nudge them a little to see if that makes nothing fall too close to n + > > 0.5 > > > > > > > > > > > > Sergey, can you look into this (its your patch) ? (just asking to make > > sure > > > > not eevryone thinks someone else will work on this) > > > > > > > > > > Yes, I can, just need to know, what is possible to do to fix this issue, > > > besides skipping the tests. > > > > most things are possible > > > > Hi, > > I am having trouble reproducing this error. These tests are fine for 32-bit > VMs on > my computers. yes, i had the same problem when i initially tested the code, it locally works on 32bit must be the exact platform or compiler ... > So the only thing I can do is to disable these tests for > these formats. > Otherwise, I need to test other changes somehow. Here is the patch, that > skips > pixfmts tests for these formats. in absence of another solution this should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
Hello, I am having trouble reproducing this error. These tests are fine for 32-bit > VMs on > my computers. So the only thing I can do is to disable these tests for > these formats. > Otherwise, I need to test other changes somehow. Here is the patch, that > skips > pixfmts tests for these formats. > > What is the conversion function which create "problem" in tests ? Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-18 23:20 GMT+03:00 Michael Niedermayer :
> On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote:
> > 2018-08-17 23:28 GMT+03:00 Michael Niedermayer :
> >
> > > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote:
> > > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote:
> > > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote:
> > > > >>>
> > > > >>> Just use av_clipf instead of FFMIN/FFMAX.
> > > > >>
> > > > >>
> > > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8.
> > > > >
> > > > > will apply
> > > > >
> > > > > thanks
> > > >
> > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be
> > > > tested for bitexact output. The gbrpf32 ones aren't, for example.
> > > > http://fate.ffmpeg.org/report.cgi?time=20180816131312=
> > > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx
> > >
> > > h
> > > i remember i had tested this locally on 32bit
> > > can something be slightly adjusted (like an offset or factor) to avoid
> any
> > > values becoming close to 0.5 and rounding differently on platforms ?
> >
> > If not the tests should skip float pixel formats or try the nearest
> > > neighbor scaler
> > >
> >
> > Can it really be the problem with scaler? Do all these failed test use
> > scaling?
> > Is not it the problem, that different platforms can give slightly
> different
> > results for
> > floating-point operations? Does input for the float format is somehow
> > generated
> > for these tests, so the input conversion is tested? Maybe it uses output
> > conversion first?
> > If it is the problem of different floating-point operations results on
> > different platforms,
>
> > maybe it is possible to use precomputed LUT for output conversion, so it
>
> I dont think we should change the "algorithm" to achive "bitexactness"
> we could of course but it feels like the wrong reason to make such a
> change. How its done should be choosen based on what is fast (and to a
> lesser extend clean, simple and maintainable)
>
>
>
> > will give
> > the same results? Or is it possible to modify tests for the float format,
> > so it will
> > check if pixels of the result are just close to some reference.
>
> Its possible to compare to a reference, we do this in some other tests,
> but thats surely more work than just disabling teh specific tests or trying
> to nudge them a little to see if that makes nothing fall too close to n +
> 0.5
>
> >
> >
> > > Sergey, can you look into this (its your patch) ? (just asking to make
> sure
> > > not eevryone thinks someone else will work on this)
> > >
> >
> > Yes, I can, just need to know, what is possible to do to fix this issue,
> > besides skipping the tests.
>
> most things are possible
>
Hi,
I am having trouble reproducing this error. These tests are fine for 32-bit
VMs on
my computers. So the only thing I can do is to disable these tests for
these formats.
Otherwise, I need to test other changes somehow. Here is the patch, that
skips
pixfmts tests for these formats.
From a92e6965f9c328fcaa18460ac9da975748272e0a Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Mon, 20 Aug 2018 23:14:07 +0300
Subject: [PATCH] tests: Disables pixfmts tests for float gray formats.
---
tests/fate-run.sh| 4 ++--
tests/ref/fate/filter-pixfmts-copy | 2 --
tests/ref/fate/filter-pixfmts-crop | 2 --
tests/ref/fate/filter-pixfmts-field | 2 --
tests/ref/fate/filter-pixfmts-fieldorder | 2 --
tests/ref/fate/filter-pixfmts-hflip | 2 --
tests/ref/fate/filter-pixfmts-il | 2 --
tests/ref/fate/filter-pixfmts-null | 2 --
tests/ref/fate/filter-pixfmts-scale | 2 --
tests/ref/fate/filter-pixfmts-transpose | 2 --
tests/ref/fate/filter-pixfmts-vflip | 2 --
11 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index aece90a01d..e8d71707b0 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -288,8 +288,8 @@ pixfmts(){
in_fmts=${outfile}_in_fmts
# exclude pixel formats which are not supported as input
-$showfiltfmts scale | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_in_fmts
-$showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); print fmt }' | sort >$scale_out_fmts
+$showfiltfmts scale | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); if (fmt !~ /grayf32.e/){ print fmt } }' | sort >$scale_in_fmts
+$showfiltfmts scale | awk -F '[ \r]' '/^OUTPUT/{ fmt=substr($3, 5); if (fmt !~ /grayf32.e/){ print fmt } }' | sort >$scale_out_fmts
comm -12 $scale_in_fmts $scale_out_fmts >$scale_exclude_fmts
$showfiltfmts $filter | awk -F '[ \r]' '/^INPUT/{ fmt=substr($3, 5); print fmt }' | sort >$in_fmts
diff --git a/tests/ref/fate/filter-pixfmts-copy b/tests/ref/fate/filter-pixfmts-copy
index 5385036a82..013b33f1c0 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -47,8 +47,6 @@ gray16be
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Sat, Aug 18, 2018 at 02:10:21PM +0300, Sergey Lavrushkin wrote: > 2018-08-17 23:28 GMT+03:00 Michael Niedermayer : > > > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote: > > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > > > >>> > > > >>> Just use av_clipf instead of FFMIN/FFMAX. > > > >> > > > >> > > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > > > > > will apply > > > > > > > > thanks > > > > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > > > tested for bitexact output. The gbrpf32 ones aren't, for example. > > > http://fate.ffmpeg.org/report.cgi?time=20180816131312= > > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx > > > > h > > i remember i had tested this locally on 32bit > > can something be slightly adjusted (like an offset or factor) to avoid any > > values becoming close to 0.5 and rounding differently on platforms ? > > If not the tests should skip float pixel formats or try the nearest > > neighbor scaler > > > > Can it really be the problem with scaler? Do all these failed test use > scaling? > Is not it the problem, that different platforms can give slightly different > results for > floating-point operations? Does input for the float format is somehow > generated > for these tests, so the input conversion is tested? Maybe it uses output > conversion first? > If it is the problem of different floating-point operations results on > different platforms, > maybe it is possible to use precomputed LUT for output conversion, so it I dont think we should change the "algorithm" to achive "bitexactness" we could of course but it feels like the wrong reason to make such a change. How its done should be choosen based on what is fast (and to a lesser extend clean, simple and maintainable) > will give > the same results? Or is it possible to modify tests for the float format, > so it will > check if pixels of the result are just close to some reference. Its possible to compare to a reference, we do this in some other tests, but thats surely more work than just disabling teh specific tests or trying to nudge them a little to see if that makes nothing fall too close to n + 0.5 > > > > Sergey, can you look into this (its your patch) ? (just asking to make sure > > not eevryone thinks someone else will work on this) > > > > Yes, I can, just need to know, what is possible to do to fix this issue, > besides skipping the tests. most things are possible > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On 8/17/2018 9:52 AM, Carl Eugen Hoyos wrote: > 2018-08-17 14:21 GMT+02:00, Sergey Lavrushkin : >> пт, 17 авг. 2018 г., 6:47 James Almer : >> >>> On 8/14/2018 1:23 PM, Michael Niedermayer wrote: On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: >> >> Just use av_clipf instead of FFMIN/FFMAX. > > > Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. will apply thanks >>> >>> This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be >>> tested for bitexact output. The gbrpf32 ones aren't, for example. >>> >>> http://fate.ffmpeg.org/report.cgi?time=20180816131312=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx >> >> >> If I am not mistaken, gbrpf32 formats are not supported in libswscale >> [because of that] > > I sincerely hope that this is not true... > >> and not tested because of that. >> >>> >>> Was a float gray pixfmt needed for this filter? Gray16 was not an option? >>> >> >> All calculations in neural network are done using floats. >> >> What can I do to fix this issue? > > Reverting to doing the conversion in the filter comes to mind... > > Carl Eugen We asked him to remove the conversions from the filter, so we're not going to tell him to roll everything back... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-17 23:28 GMT+03:00 Michael Niedermayer : > On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote: > > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > > >>> > > >>> Just use av_clipf instead of FFMIN/FFMAX. > > >> > > >> > > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > > > will apply > > > > > > thanks > > > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > > tested for bitexact output. The gbrpf32 ones aren't, for example. > > http://fate.ffmpeg.org/report.cgi?time=20180816131312= > x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx > > h > i remember i had tested this locally on 32bit > can something be slightly adjusted (like an offset or factor) to avoid any > values becoming close to 0.5 and rounding differently on platforms ? If not the tests should skip float pixel formats or try the nearest > neighbor scaler > Can it really be the problem with scaler? Do all these failed test use scaling? Is not it the problem, that different platforms can give slightly different results for floating-point operations? Does input for the float format is somehow generated for these tests, so the input conversion is tested? Maybe it uses output conversion first? If it is the problem of different floating-point operations results on different platforms, maybe it is possible to use precomputed LUT for output conversion, so it will give the same results? Or is it possible to modify tests for the float format, so it will check if pixels of the result are just close to some reference. > Sergey, can you look into this (its your patch) ? (just asking to make sure > not eevryone thinks someone else will work on this) > Yes, I can, just need to know, what is possible to do to fix this issue, besides skipping the tests. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Fri, Aug 17, 2018 at 12:46:52AM -0300, James Almer wrote: > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > >>> > >>> Just use av_clipf instead of FFMIN/FFMAX. > >> > >> > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > will apply > > > > thanks > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > tested for bitexact output. The gbrpf32 ones aren't, for example. > http://fate.ffmpeg.org/report.cgi?time=20180816131312=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx h i remember i had tested this locally on 32bit can something be slightly adjusted (like an offset or factor) to avoid any values becoming close to 0.5 and rounding differently on platforms ? If not the tests should skip float pixel formats or try the nearest neighbor scaler Sergey, can you look into this (its your patch) ? (just asking to make sure not eevryone thinks someone else will work on this) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-17 14:21 GMT+02:00, Sergey Lavrushkin : > пт, 17 авг. 2018 г., 6:47 James Almer : > >> On 8/14/2018 1:23 PM, Michael Niedermayer wrote: >> > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: >> >>> >> >>> Just use av_clipf instead of FFMIN/FFMAX. >> >> >> >> >> >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. >> > >> > will apply >> > >> > thanks >> >> This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be >> tested for bitexact output. The gbrpf32 ones aren't, for example. >> >> http://fate.ffmpeg.org/report.cgi?time=20180816131312=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx > > > If I am not mistaken, gbrpf32 formats are not supported in libswscale > [because of that] I sincerely hope that this is not true... > and not tested because of that. > >> >> Was a float gray pixfmt needed for this filter? Gray16 was not an option? >> > > All calculations in neural network are done using floats. > > What can I do to fix this issue? Reverting to doing the conversion in the filter comes to mind... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
пт, 17 авг. 2018 г., 6:47 James Almer : > On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > >>> > >>> Just use av_clipf instead of FFMIN/FFMAX. > >> > >> > >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > > > will apply > > > > thanks > > This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be > tested for bitexact output. The gbrpf32 ones aren't, for example. > > http://fate.ffmpeg.org/report.cgi?time=20180816131312=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx If I am not mistaken, gbrpf32 formats are not supported in libswscale and not tested because of that. > > Was a float gray pixfmt needed for this filter? Gray16 was not an option? > All calculations in neural network are done using floats. What can I do to fix this issue? Can I get a VM image for this host to test it? > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On 8/14/2018 1:23 PM, Michael Niedermayer wrote: > On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: >>> >>> Just use av_clipf instead of FFMIN/FFMAX. >> >> >> Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. > > will apply > > thanks This broke fate on some 32bit hosts. Guess float pixfmts shouldn't be tested for bitexact output. The gbrpf32 ones aren't, for example. http://fate.ffmpeg.org/report.cgi?time=20180816131312=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx Was a float gray pixfmt needed for this filter? Gray16 was not an option? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Mon, Aug 13, 2018 at 04:58:42PM +0300, Sergey Lavrushkin wrote: > > > > Just use av_clipf instead of FFMIN/FFMAX. > > > Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8. will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
>
> Just use av_clipf instead of FFMIN/FFMAX.
Changed FFMIN/FFMAX to av_clip_uint16 and av_clip_uint8.
From 210e497d76328947fdf424b169728fa728cc18f2 Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Fri, 3 Aug 2018 18:06:50 +0300
Subject: [PATCH 5/9] libswscale: Adds conversions from/to float gray format.
---
libswscale/input.c | 38 +++
libswscale/output.c | 105 +++
libswscale/ppc/swscale_altivec.c | 1 +
libswscale/swscale_internal.h| 9 +++
libswscale/swscale_unscaled.c| 54 +++-
libswscale/utils.c | 20 +-
libswscale/x86/swscale_template.c| 3 +-
tests/ref/fate/filter-pixdesc-grayf32be | 1 +
tests/ref/fate/filter-pixdesc-grayf32le | 1 +
tests/ref/fate/filter-pixfmts-copy | 2 +
tests/ref/fate/filter-pixfmts-crop | 2 +
tests/ref/fate/filter-pixfmts-field | 2 +
tests/ref/fate/filter-pixfmts-fieldorder | 2 +
tests/ref/fate/filter-pixfmts-hflip | 2 +
tests/ref/fate/filter-pixfmts-il | 2 +
tests/ref/fate/filter-pixfmts-null | 2 +
tests/ref/fate/filter-pixfmts-scale | 2 +
tests/ref/fate/filter-pixfmts-transpose | 2 +
tests/ref/fate/filter-pixfmts-vflip | 2 +
19 files changed, 248 insertions(+), 4 deletions(-)
create mode 100644 tests/ref/fate/filter-pixdesc-grayf32be
create mode 100644 tests/ref/fate/filter-pixdesc-grayf32le
diff --git a/libswscale/input.c b/libswscale/input.c
index 3fd3a5d81e..4099c19c2b 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -942,6 +942,30 @@ static av_always_inline void planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
}
#undef rdpx
+static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const uint8_t *_src, const uint8_t *unused1,
+const uint8_t *unused2, int width, uint32_t *unused)
+{
+int i;
+const float *src = (const float *)_src;
+uint16_t *dst= (uint16_t *)_dst;
+
+for (i = 0; i < width; ++i){
+dst[i] = av_clip_uint16(lrintf(65535.0f * src[i]));
+}
+}
+
+static av_always_inline void grayf32ToY16_bswap_c(uint8_t *_dst, const uint8_t *_src, const uint8_t *unused1,
+ const uint8_t *unused2, int width, uint32_t *unused)
+{
+int i;
+const uint32_t *src = (const uint32_t *)_src;
+uint16_t *dst= (uint16_t *)_dst;
+
+for (i = 0; i < width; ++i){
+dst[i] = av_clip_uint16(lrintf(65535.0f * av_int2float(av_bswap32(src[i];
+}
+}
+
#define rgb9plus_planar_funcs_endian(nbits, endian_name, endian)\
static void planar_rgb##nbits##endian_name##_to_y(uint8_t *dst, const uint8_t *src[4], \
int w, int32_t *rgb2yuv) \
@@ -1538,6 +1562,20 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_P010BE:
c->lumToYV12 = p010BEToY_c;
break;
+case AV_PIX_FMT_GRAYF32LE:
+#if HAVE_BIGENDIAN
+c->lumToYV12 = grayf32ToY16_bswap_c;
+#else
+c->lumToYV12 = grayf32ToY16_c;
+#endif
+break;
+case AV_PIX_FMT_GRAYF32BE:
+#if HAVE_BIGENDIAN
+c->lumToYV12 = grayf32ToY16_c;
+#else
+c->lumToYV12 = grayf32ToY16_bswap_c;
+#endif
+break;
}
if (c->needAlpha) {
if (is16BPS(srcFormat) || isNBPS(srcFormat)) {
diff --git a/libswscale/output.c b/libswscale/output.c
index 0af2fffea4..de8637aa3b 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -208,6 +208,105 @@ static void yuv2p016cX_c(SwsContext *c, const int16_t *chrFilter, int chrFilterS
}
}
+static av_always_inline void
+yuv2plane1_float_c_template(const int32_t *src, float *dest, int dstW)
+{
+static const int big_endian = HAVE_BIGENDIAN;
+static const int shift = 3;
+static const float float_mult = 1.0f / 65535.0f;
+int i, val;
+uint16_t val_uint;
+
+for (i = 0; i < dstW; ++i){
+val = src[i] + (1 << (shift - 1));
+output_pixel(_uint, val, 0, uint);
+dest[i] = float_mult * (float)val_uint;
+}
+}
+
+static av_always_inline void
+yuv2plane1_float_bswap_c_template(const int32_t *src, uint32_t *dest, int dstW)
+{
+static const int big_endian = HAVE_BIGENDIAN;
+static const int shift = 3;
+static const float float_mult = 1.0f / 65535.0f;
+int i, val;
+uint16_t val_uint;
+
+for (i = 0; i < dstW; ++i){
+val = src[i] + (1 << (shift - 1));
+output_pixel(_uint, val, 0, uint);
+dest[i] = av_bswap32(av_float2int(float_mult * (float)val_uint));
+}
+}
+
+static av_always_inline void
+yuv2planeX_float_c_template(const int16_t *filter, int filterSize, const int32_t **src,
+float *dest, int dstW)
+{
+static const int big_endian = HAVE_BIGENDIAN;
+static
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Sat, 11 Aug 2018 at 23:31, Sergey Lavrushkin wrote:
> 2018-08-12 0:45 GMT+03:00 Michael Niedermayer :
>
> > On Sat, Aug 11, 2018 at 05:52:32PM +0300, Sergey Lavrushkin wrote:
> > > 2018-08-10 20:24 GMT+03:00 Michael Niedermayer >:
> > >
> > > > On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> > > > > Here are updated patches with fixes. I updated conversion
> functions,
> > so
> > > > > they should
> > > > > properly work with format for different endianness.
> > > > [...]
> > > > > diff --git a/libswscale/input.c b/libswscale/input.c
> > > > > index 3fd3a5d81e..0e016d387f 100644
> > > > > --- a/libswscale/input.c
> > > > > +++ b/libswscale/input.c
> > > > > @@ -942,6 +942,30 @@ static av_always_inline void
> > > > planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
> > > > > }
> > > > > #undef rdpx
> > > > >
> > > > > +static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const
> > > > uint8_t *_src, const uint8_t *unused1,
> > > > > +const uint8_t
> *unused2,
> > int
> > > > width, uint32_t *unused)
> > > > > +{
> > > > > +int i;
> > > > > +const float *src = (const float *)_src;
> > > > > +uint16_t *dst= (uint16_t *)_dst;
> > > > > +
> > > > > +for (i = 0; i < width; ++i){
> > > > > +dst[i] = lrintf(65535.0f * FFMIN(FFMAX(src[i], 0.0f),
> > 1.0f));
> > > > > +}
> > > > > +}
> > > >
> > > > is it faster to clip the float before lrintf() than the integer
> > afterwards
> > > > ?
> > > >
> > >
> > > Clipping integers is faster, switched to it.
> > >
> > >
> > > > [...]
> > > > > diff --git a/libswscale/output.c b/libswscale/output.c
> > > > > index 0af2fffea4..cd408fb285 100644
> > > > > --- a/libswscale/output.c
> > > > > +++ b/libswscale/output.c
> > > > > @@ -208,6 +208,121 @@ static void yuv2p016cX_c(SwsContext *c, const
> > > > int16_t *chrFilter, int chrFilterS
> > > > > }
> > > > > }
> > > > >
> > > > > +static av_always_inline void
> > > > > +yuv2plane1_float_c_template(const int32_t *src, float *dest, int
> > dstW)
> > > > > +{
> > > > > +#if HAVE_BIGENDIAN
> > > > > +static const int big_endian = 1;
> > > > > +#else
> > > > > +static const int big_endian = 0;
> > > > > +#endif
> > > >
> > > > you can use HAVE_BIGENDIAN in place of big_endian
> > > > its either 0 or 1 already
> > > > or static const int big_endian = HAVE_BIGENDIAN
> > > >
> > >
> > > Ok.
> > >
> > > Here is updated patch.
> >
> > > libswscale/input.c | 38 +++
> > > libswscale/output.c | 105
> > +++
> > > libswscale/ppc/swscale_altivec.c |1
> > > libswscale/swscale_internal.h|9 ++
> > > libswscale/swscale_unscaled.c| 54 +++
> > > libswscale/utils.c | 20 +
> > > libswscale/x86/swscale_template.c|3
> > > tests/ref/fate/filter-pixdesc-grayf32be |1
> > > tests/ref/fate/filter-pixdesc-grayf32le |1
> > > tests/ref/fate/filter-pixfmts-copy |2
> > > tests/ref/fate/filter-pixfmts-crop |2
> > > tests/ref/fate/filter-pixfmts-field |2
> > > tests/ref/fate/filter-pixfmts-fieldorder |2
> > > tests/ref/fate/filter-pixfmts-hflip |2
> > > tests/ref/fate/filter-pixfmts-il |2
> > > tests/ref/fate/filter-pixfmts-null |2
> > > tests/ref/fate/filter-pixfmts-scale |2
> > > tests/ref/fate/filter-pixfmts-transpose |2
> > > tests/ref/fate/filter-pixfmts-vflip |2
> > > 19 files changed, 248 insertions(+), 4 deletions(-)
> > > db401051d0e42132f7ce76cb78de584951be704b 0005-libswscale-Adds-
> > conversions-from-to-float-gray-forma.patch
> > > From cf523bcb50537abbf6daf0eb799341d8b706d366 Mon Sep 17 00:00:00 2001
> > > From: Sergey Lavrushkin
> > > Date: Fri, 3 Aug 2018 18:06:50 +0300
> > > Subject: [PATCH 5/9] libswscale: Adds conversions from/to float gray
> > format.
> > >
> > > ---
> > > libswscale/input.c | 38 +++
> > > libswscale/output.c | 105
> > +++
> > > libswscale/ppc/swscale_altivec.c | 1 +
> > > libswscale/swscale_internal.h| 9 +++
> > > libswscale/swscale_unscaled.c| 54 +++-
> > > libswscale/utils.c | 20 +-
> > > libswscale/x86/swscale_template.c| 3 +-
> > > tests/ref/fate/filter-pixdesc-grayf32be | 1 +
> > > tests/ref/fate/filter-pixdesc-grayf32le | 1 +
> > > tests/ref/fate/filter-pixfmts-copy | 2 +
> > > tests/ref/fate/filter-pixfmts-crop | 2 +
> > > tests/ref/fate/filter-pixfmts-field | 2 +
> > > tests/ref/fate/filter-pixfmts-fieldorder | 2 +
> > > tests/ref/fate/filter-pixfmts-hflip | 2 +
> > > tests/ref/fate/filter-pixfmts-il | 2 +
> > > tests/ref/fate/filter-pixfmts-null | 2 +
> > >
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-12 0:45 GMT+03:00 Michael Niedermayer :
> On Sat, Aug 11, 2018 at 05:52:32PM +0300, Sergey Lavrushkin wrote:
> > 2018-08-10 20:24 GMT+03:00 Michael Niedermayer :
> >
> > > On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> > > > Here are updated patches with fixes. I updated conversion functions,
> so
> > > > they should
> > > > properly work with format for different endianness.
> > > [...]
> > > > diff --git a/libswscale/input.c b/libswscale/input.c
> > > > index 3fd3a5d81e..0e016d387f 100644
> > > > --- a/libswscale/input.c
> > > > +++ b/libswscale/input.c
> > > > @@ -942,6 +942,30 @@ static av_always_inline void
> > > planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
> > > > }
> > > > #undef rdpx
> > > >
> > > > +static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const
> > > uint8_t *_src, const uint8_t *unused1,
> > > > +const uint8_t *unused2,
> int
> > > width, uint32_t *unused)
> > > > +{
> > > > +int i;
> > > > +const float *src = (const float *)_src;
> > > > +uint16_t *dst= (uint16_t *)_dst;
> > > > +
> > > > +for (i = 0; i < width; ++i){
> > > > +dst[i] = lrintf(65535.0f * FFMIN(FFMAX(src[i], 0.0f),
> 1.0f));
> > > > +}
> > > > +}
> > >
> > > is it faster to clip the float before lrintf() than the integer
> afterwards
> > > ?
> > >
> >
> > Clipping integers is faster, switched to it.
> >
> >
> > > [...]
> > > > diff --git a/libswscale/output.c b/libswscale/output.c
> > > > index 0af2fffea4..cd408fb285 100644
> > > > --- a/libswscale/output.c
> > > > +++ b/libswscale/output.c
> > > > @@ -208,6 +208,121 @@ static void yuv2p016cX_c(SwsContext *c, const
> > > int16_t *chrFilter, int chrFilterS
> > > > }
> > > > }
> > > >
> > > > +static av_always_inline void
> > > > +yuv2plane1_float_c_template(const int32_t *src, float *dest, int
> dstW)
> > > > +{
> > > > +#if HAVE_BIGENDIAN
> > > > +static const int big_endian = 1;
> > > > +#else
> > > > +static const int big_endian = 0;
> > > > +#endif
> > >
> > > you can use HAVE_BIGENDIAN in place of big_endian
> > > its either 0 or 1 already
> > > or static const int big_endian = HAVE_BIGENDIAN
> > >
> >
> > Ok.
> >
> > Here is updated patch.
>
> > libswscale/input.c | 38 +++
> > libswscale/output.c | 105
> +++
> > libswscale/ppc/swscale_altivec.c |1
> > libswscale/swscale_internal.h|9 ++
> > libswscale/swscale_unscaled.c| 54 +++
> > libswscale/utils.c | 20 +
> > libswscale/x86/swscale_template.c|3
> > tests/ref/fate/filter-pixdesc-grayf32be |1
> > tests/ref/fate/filter-pixdesc-grayf32le |1
> > tests/ref/fate/filter-pixfmts-copy |2
> > tests/ref/fate/filter-pixfmts-crop |2
> > tests/ref/fate/filter-pixfmts-field |2
> > tests/ref/fate/filter-pixfmts-fieldorder |2
> > tests/ref/fate/filter-pixfmts-hflip |2
> > tests/ref/fate/filter-pixfmts-il |2
> > tests/ref/fate/filter-pixfmts-null |2
> > tests/ref/fate/filter-pixfmts-scale |2
> > tests/ref/fate/filter-pixfmts-transpose |2
> > tests/ref/fate/filter-pixfmts-vflip |2
> > 19 files changed, 248 insertions(+), 4 deletions(-)
> > db401051d0e42132f7ce76cb78de584951be704b 0005-libswscale-Adds-
> conversions-from-to-float-gray-forma.patch
> > From cf523bcb50537abbf6daf0eb799341d8b706d366 Mon Sep 17 00:00:00 2001
> > From: Sergey Lavrushkin
> > Date: Fri, 3 Aug 2018 18:06:50 +0300
> > Subject: [PATCH 5/9] libswscale: Adds conversions from/to float gray
> format.
> >
> > ---
> > libswscale/input.c | 38 +++
> > libswscale/output.c | 105
> +++
> > libswscale/ppc/swscale_altivec.c | 1 +
> > libswscale/swscale_internal.h| 9 +++
> > libswscale/swscale_unscaled.c| 54 +++-
> > libswscale/utils.c | 20 +-
> > libswscale/x86/swscale_template.c| 3 +-
> > tests/ref/fate/filter-pixdesc-grayf32be | 1 +
> > tests/ref/fate/filter-pixdesc-grayf32le | 1 +
> > tests/ref/fate/filter-pixfmts-copy | 2 +
> > tests/ref/fate/filter-pixfmts-crop | 2 +
> > tests/ref/fate/filter-pixfmts-field | 2 +
> > tests/ref/fate/filter-pixfmts-fieldorder | 2 +
> > tests/ref/fate/filter-pixfmts-hflip | 2 +
> > tests/ref/fate/filter-pixfmts-il | 2 +
> > tests/ref/fate/filter-pixfmts-null | 2 +
> > tests/ref/fate/filter-pixfmts-scale | 2 +
> > tests/ref/fate/filter-pixfmts-transpose | 2 +
> > tests/ref/fate/filter-pixfmts-vflip | 2 +
> > 19 files changed, 248 insertions(+), 4 deletions(-)
> > create mode 100644 tests/ref/fate/filter-pixdesc-grayf32be
> > create mode 100644
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Sat, Aug 11, 2018 at 05:52:32PM +0300, Sergey Lavrushkin wrote:
> 2018-08-10 20:24 GMT+03:00 Michael Niedermayer :
>
> > On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> > > Here are updated patches with fixes. I updated conversion functions, so
> > > they should
> > > properly work with format for different endianness.
> > [...]
> > > diff --git a/libswscale/input.c b/libswscale/input.c
> > > index 3fd3a5d81e..0e016d387f 100644
> > > --- a/libswscale/input.c
> > > +++ b/libswscale/input.c
> > > @@ -942,6 +942,30 @@ static av_always_inline void
> > planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
> > > }
> > > #undef rdpx
> > >
> > > +static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const
> > uint8_t *_src, const uint8_t *unused1,
> > > +const uint8_t *unused2, int
> > width, uint32_t *unused)
> > > +{
> > > +int i;
> > > +const float *src = (const float *)_src;
> > > +uint16_t *dst= (uint16_t *)_dst;
> > > +
> > > +for (i = 0; i < width; ++i){
> > > +dst[i] = lrintf(65535.0f * FFMIN(FFMAX(src[i], 0.0f), 1.0f));
> > > +}
> > > +}
> >
> > is it faster to clip the float before lrintf() than the integer afterwards
> > ?
> >
>
> Clipping integers is faster, switched to it.
>
>
> > [...]
> > > diff --git a/libswscale/output.c b/libswscale/output.c
> > > index 0af2fffea4..cd408fb285 100644
> > > --- a/libswscale/output.c
> > > +++ b/libswscale/output.c
> > > @@ -208,6 +208,121 @@ static void yuv2p016cX_c(SwsContext *c, const
> > int16_t *chrFilter, int chrFilterS
> > > }
> > > }
> > >
> > > +static av_always_inline void
> > > +yuv2plane1_float_c_template(const int32_t *src, float *dest, int dstW)
> > > +{
> > > +#if HAVE_BIGENDIAN
> > > +static const int big_endian = 1;
> > > +#else
> > > +static const int big_endian = 0;
> > > +#endif
> >
> > you can use HAVE_BIGENDIAN in place of big_endian
> > its either 0 or 1 already
> > or static const int big_endian = HAVE_BIGENDIAN
> >
>
> Ok.
>
> Here is updated patch.
> libswscale/input.c | 38 +++
> libswscale/output.c | 105
> +++
> libswscale/ppc/swscale_altivec.c |1
> libswscale/swscale_internal.h|9 ++
> libswscale/swscale_unscaled.c| 54 +++
> libswscale/utils.c | 20 +
> libswscale/x86/swscale_template.c|3
> tests/ref/fate/filter-pixdesc-grayf32be |1
> tests/ref/fate/filter-pixdesc-grayf32le |1
> tests/ref/fate/filter-pixfmts-copy |2
> tests/ref/fate/filter-pixfmts-crop |2
> tests/ref/fate/filter-pixfmts-field |2
> tests/ref/fate/filter-pixfmts-fieldorder |2
> tests/ref/fate/filter-pixfmts-hflip |2
> tests/ref/fate/filter-pixfmts-il |2
> tests/ref/fate/filter-pixfmts-null |2
> tests/ref/fate/filter-pixfmts-scale |2
> tests/ref/fate/filter-pixfmts-transpose |2
> tests/ref/fate/filter-pixfmts-vflip |2
> 19 files changed, 248 insertions(+), 4 deletions(-)
> db401051d0e42132f7ce76cb78de584951be704b
> 0005-libswscale-Adds-conversions-from-to-float-gray-forma.patch
> From cf523bcb50537abbf6daf0eb799341d8b706d366 Mon Sep 17 00:00:00 2001
> From: Sergey Lavrushkin
> Date: Fri, 3 Aug 2018 18:06:50 +0300
> Subject: [PATCH 5/9] libswscale: Adds conversions from/to float gray format.
>
> ---
> libswscale/input.c | 38 +++
> libswscale/output.c | 105
> +++
> libswscale/ppc/swscale_altivec.c | 1 +
> libswscale/swscale_internal.h| 9 +++
> libswscale/swscale_unscaled.c| 54 +++-
> libswscale/utils.c | 20 +-
> libswscale/x86/swscale_template.c| 3 +-
> tests/ref/fate/filter-pixdesc-grayf32be | 1 +
> tests/ref/fate/filter-pixdesc-grayf32le | 1 +
> tests/ref/fate/filter-pixfmts-copy | 2 +
> tests/ref/fate/filter-pixfmts-crop | 2 +
> tests/ref/fate/filter-pixfmts-field | 2 +
> tests/ref/fate/filter-pixfmts-fieldorder | 2 +
> tests/ref/fate/filter-pixfmts-hflip | 2 +
> tests/ref/fate/filter-pixfmts-il | 2 +
> tests/ref/fate/filter-pixfmts-null | 2 +
> tests/ref/fate/filter-pixfmts-scale | 2 +
> tests/ref/fate/filter-pixfmts-transpose | 2 +
> tests/ref/fate/filter-pixfmts-vflip | 2 +
> 19 files changed, 248 insertions(+), 4 deletions(-)
> create mode 100644 tests/ref/fate/filter-pixdesc-grayf32be
> create mode 100644 tests/ref/fate/filter-pixdesc-grayf32le
>
> diff --git a/libswscale/input.c b/libswscale/input.c
> index 3fd3a5d81e..7e45df50ce 100644
> --- a/libswscale/input.c
> +++ b/libswscale/input.c
> @@ -942,6 +942,30 @@ static av_always_inline void planar_rgb16_to_uv(uint8_t
> *_dstU,
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-10 20:24 GMT+03:00 Michael Niedermayer :
> On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> > Here are updated patches with fixes. I updated conversion functions, so
> > they should
> > properly work with format for different endianness.
> [...]
> > diff --git a/libswscale/input.c b/libswscale/input.c
> > index 3fd3a5d81e..0e016d387f 100644
> > --- a/libswscale/input.c
> > +++ b/libswscale/input.c
> > @@ -942,6 +942,30 @@ static av_always_inline void
> planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
> > }
> > #undef rdpx
> >
> > +static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const
> uint8_t *_src, const uint8_t *unused1,
> > +const uint8_t *unused2, int
> width, uint32_t *unused)
> > +{
> > +int i;
> > +const float *src = (const float *)_src;
> > +uint16_t *dst= (uint16_t *)_dst;
> > +
> > +for (i = 0; i < width; ++i){
> > +dst[i] = lrintf(65535.0f * FFMIN(FFMAX(src[i], 0.0f), 1.0f));
> > +}
> > +}
>
> is it faster to clip the float before lrintf() than the integer afterwards
> ?
>
Clipping integers is faster, switched to it.
> [...]
> > diff --git a/libswscale/output.c b/libswscale/output.c
> > index 0af2fffea4..cd408fb285 100644
> > --- a/libswscale/output.c
> > +++ b/libswscale/output.c
> > @@ -208,6 +208,121 @@ static void yuv2p016cX_c(SwsContext *c, const
> int16_t *chrFilter, int chrFilterS
> > }
> > }
> >
> > +static av_always_inline void
> > +yuv2plane1_float_c_template(const int32_t *src, float *dest, int dstW)
> > +{
> > +#if HAVE_BIGENDIAN
> > +static const int big_endian = 1;
> > +#else
> > +static const int big_endian = 0;
> > +#endif
>
> you can use HAVE_BIGENDIAN in place of big_endian
> its either 0 or 1 already
> or static const int big_endian = HAVE_BIGENDIAN
>
Ok.
Here is updated patch.
From cf523bcb50537abbf6daf0eb799341d8b706d366 Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Fri, 3 Aug 2018 18:06:50 +0300
Subject: [PATCH 5/9] libswscale: Adds conversions from/to float gray format.
---
libswscale/input.c | 38 +++
libswscale/output.c | 105 +++
libswscale/ppc/swscale_altivec.c | 1 +
libswscale/swscale_internal.h| 9 +++
libswscale/swscale_unscaled.c| 54 +++-
libswscale/utils.c | 20 +-
libswscale/x86/swscale_template.c| 3 +-
tests/ref/fate/filter-pixdesc-grayf32be | 1 +
tests/ref/fate/filter-pixdesc-grayf32le | 1 +
tests/ref/fate/filter-pixfmts-copy | 2 +
tests/ref/fate/filter-pixfmts-crop | 2 +
tests/ref/fate/filter-pixfmts-field | 2 +
tests/ref/fate/filter-pixfmts-fieldorder | 2 +
tests/ref/fate/filter-pixfmts-hflip | 2 +
tests/ref/fate/filter-pixfmts-il | 2 +
tests/ref/fate/filter-pixfmts-null | 2 +
tests/ref/fate/filter-pixfmts-scale | 2 +
tests/ref/fate/filter-pixfmts-transpose | 2 +
tests/ref/fate/filter-pixfmts-vflip | 2 +
19 files changed, 248 insertions(+), 4 deletions(-)
create mode 100644 tests/ref/fate/filter-pixdesc-grayf32be
create mode 100644 tests/ref/fate/filter-pixdesc-grayf32le
diff --git a/libswscale/input.c b/libswscale/input.c
index 3fd3a5d81e..7e45df50ce 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -942,6 +942,30 @@ static av_always_inline void planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
}
#undef rdpx
+static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const uint8_t *_src, const uint8_t *unused1,
+const uint8_t *unused2, int width, uint32_t *unused)
+{
+int i;
+const float *src = (const float *)_src;
+uint16_t *dst= (uint16_t *)_dst;
+
+for (i = 0; i < width; ++i){
+dst[i] = FFMIN(FFMAX(lrintf(65535.0f * src[i]), 0), 65535);
+}
+}
+
+static av_always_inline void grayf32ToY16_bswap_c(uint8_t *_dst, const uint8_t *_src, const uint8_t *unused1,
+ const uint8_t *unused2, int width, uint32_t *unused)
+{
+int i;
+const uint32_t *src = (const uint32_t *)_src;
+uint16_t *dst= (uint16_t *)_dst;
+
+for (i = 0; i < width; ++i){
+dst[i] = FFMIN(FFMAX(lrintf(65535.0f * av_int2float(av_bswap32(src[i]))), 0.0f), 65535);
+}
+}
+
#define rgb9plus_planar_funcs_endian(nbits, endian_name, endian)\
static void planar_rgb##nbits##endian_name##_to_y(uint8_t *dst, const uint8_t *src[4], \
int w, int32_t *rgb2yuv) \
@@ -1538,6 +1562,20 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_P010BE:
c->lumToYV12 = p010BEToY_c;
break;
+case AV_PIX_FMT_GRAYF32LE:
+#if HAVE_BIGENDIAN
+c->lumToYV12 = grayf32ToY16_bswap_c;
+#else
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> Here are updated patches with fixes. I updated conversion functions, so
> they should
> properly work with format for different endianness.
>
> 2018-08-08 1:47 GMT+03:00 Michael Niedermayer :
>
> > On Tue, Aug 07, 2018 at 12:17:58AM +0300, Sergey Lavrushkin wrote:
> > > I split patch to one for libavutil and another for libswscale,
> > > also added LUT for unscaled conversion, added
> > > conversions for scaling and updated fate tests.
> >
> > > libavutil/pixdesc.c | 22 ++
> > > libavutil/pixfmt.h |5 +
> > > libavutil/version.h |2 +-
> > > tests/ref/fate/sws-pixdesc-query |3 +++
> > > 4 files changed, 31 insertions(+), 1 deletion(-)
> > > b58f328f5d90954c62957f127b1acbfad5795a4d 0004-libavutil-Adds-gray-
> > floating-point-pixel-formats.patch
> > > From 8bcc10b49c41612b4d6549e64d90acf3f0b3fc6a Mon Sep 17 00:00:00 2001
> > > From: Sergey Lavrushkin
> > > Date: Fri, 3 Aug 2018 18:02:49 +0300
> > > Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.
> > >
> > > ---
> > > libavutil/pixdesc.c | 22 ++
> > > libavutil/pixfmt.h | 5 +
> > > libavutil/version.h | 2 +-
> > > tests/ref/fate/sws-pixdesc-query | 3 +++
> > > 4 files changed, 31 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> > > index 96e079584a..970a83214c 100644
> > > --- a/libavutil/pixdesc.c
> > > +++ b/libavutil/pixdesc.c
> > > @@ -2206,6 +2206,28 @@ static const AVPixFmtDescriptor
> > av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> > > .name = "opencl",
> > > .flags = AV_PIX_FMT_FLAG_HWACCEL,
> > > },
> > > +[AV_PIX_FMT_GRAYF32BE] = {
> > > +.name = "grayf32be",
> > > +.nb_components = 1,
> > > +.log2_chroma_w = 0,
> > > +.log2_chroma_h = 0,
> > > +.comp = {
> > > +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> > > +},
> > > +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
> > > +.alias = "yf32be",
> > > +},
> > > +[AV_PIX_FMT_GRAYF32LE] = {
> > > +.name = "grayf32le",
> > > +.nb_components = 1,
> > > +.log2_chroma_w = 0,
> > > +.log2_chroma_h = 0,
> > > +.comp = {
> > > +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> > > +},
> > > +.flags = AV_PIX_FMT_FLAG_FLOAT,
> > > +.alias = "yf32le",
> > > +},
> > > };
> > > #if FF_API_PLUS1_MINUS1
> > > FF_ENABLE_DEPRECATION_WARNINGS
> > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > > index 2b3307845e..7b254732d8 100644
> > > --- a/libavutil/pixfmt.h
> > > +++ b/libavutil/pixfmt.h
> > > @@ -337,6 +337,9 @@ enum AVPixelFormat {
> > > AV_PIX_FMT_GRAY14BE, /// > > AV_PIX_FMT_GRAY14LE, /// > >
> > > +AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp,
> > big-endian
> > > +AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
> > little-endian
> > > +
> > > AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS
> > if you want to link with shared libav* because the number of formats might
> > differ between versions
> > > };
> > >
> > > @@ -405,6 +408,8 @@ enum AVPixelFormat {
> > > #define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
> > > #define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
> > >
> > > +#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
> > > +
> > > #define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
> > > #define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
> > > #define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
> > > diff --git a/libavutil/version.h b/libavutil/version.h
> > > index 44bdebdc93..5205c5bc60 100644
> > > --- a/libavutil/version.h
> > > +++ b/libavutil/version.h
> >
> > > @@ -79,7 +79,7 @@
> > > */
> > >
> > > #define LIBAVUTIL_VERSION_MAJOR 56
> > > -#define LIBAVUTIL_VERSION_MINOR 18
> > > +#define LIBAVUTIL_VERSION_MINOR 19
> > > #define LIBAVUTIL_VERSION_MICRO 102
> >
> > a bump to minor must reset micro to 100
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > In a rich man's house there is no place to spit but his face.
> > -- Diogenes of Sinope
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> libavutil/pixdesc.c | 22 ++
> libavutil/pixfmt.h |5 +
> libavutil/version.h |4 ++--
> tests/ref/fate/sws-pixdesc-query |3 +++
> 4 files changed, 32 insertions(+), 2
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> Here are updated patches with fixes. I updated conversion functions, so
> they should
> properly work with format for different endianness.
[...]
> diff --git a/libswscale/input.c b/libswscale/input.c
> index 3fd3a5d81e..0e016d387f 100644
> --- a/libswscale/input.c
> +++ b/libswscale/input.c
> @@ -942,6 +942,30 @@ static av_always_inline void planar_rgb16_to_uv(uint8_t
> *_dstU, uint8_t *_dstV,
> }
> #undef rdpx
>
> +static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const uint8_t
> *_src, const uint8_t *unused1,
> +const uint8_t *unused2, int
> width, uint32_t *unused)
> +{
> +int i;
> +const float *src = (const float *)_src;
> +uint16_t *dst= (uint16_t *)_dst;
> +
> +for (i = 0; i < width; ++i){
> +dst[i] = lrintf(65535.0f * FFMIN(FFMAX(src[i], 0.0f), 1.0f));
> +}
> +}
is it faster to clip the float before lrintf() than the integer afterwards ?
[...]
> diff --git a/libswscale/output.c b/libswscale/output.c
> index 0af2fffea4..cd408fb285 100644
> --- a/libswscale/output.c
> +++ b/libswscale/output.c
> @@ -208,6 +208,121 @@ static void yuv2p016cX_c(SwsContext *c, const int16_t
> *chrFilter, int chrFilterS
> }
> }
>
> +static av_always_inline void
> +yuv2plane1_float_c_template(const int32_t *src, float *dest, int dstW)
> +{
> +#if HAVE_BIGENDIAN
> +static const int big_endian = 1;
> +#else
> +static const int big_endian = 0;
> +#endif
you can use HAVE_BIGENDIAN in place of big_endian
its either 0 or 1 already
or static const int big_endian = HAVE_BIGENDIAN
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
Here are updated patches with fixes. I updated conversion functions, so
they should
properly work with format for different endianness.
2018-08-08 1:47 GMT+03:00 Michael Niedermayer :
> On Tue, Aug 07, 2018 at 12:17:58AM +0300, Sergey Lavrushkin wrote:
> > I split patch to one for libavutil and another for libswscale,
> > also added LUT for unscaled conversion, added
> > conversions for scaling and updated fate tests.
>
> > libavutil/pixdesc.c | 22 ++
> > libavutil/pixfmt.h |5 +
> > libavutil/version.h |2 +-
> > tests/ref/fate/sws-pixdesc-query |3 +++
> > 4 files changed, 31 insertions(+), 1 deletion(-)
> > b58f328f5d90954c62957f127b1acbfad5795a4d 0004-libavutil-Adds-gray-
> floating-point-pixel-formats.patch
> > From 8bcc10b49c41612b4d6549e64d90acf3f0b3fc6a Mon Sep 17 00:00:00 2001
> > From: Sergey Lavrushkin
> > Date: Fri, 3 Aug 2018 18:02:49 +0300
> > Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.
> >
> > ---
> > libavutil/pixdesc.c | 22 ++
> > libavutil/pixfmt.h | 5 +
> > libavutil/version.h | 2 +-
> > tests/ref/fate/sws-pixdesc-query | 3 +++
> > 4 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> > index 96e079584a..970a83214c 100644
> > --- a/libavutil/pixdesc.c
> > +++ b/libavutil/pixdesc.c
> > @@ -2206,6 +2206,28 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> > .name = "opencl",
> > .flags = AV_PIX_FMT_FLAG_HWACCEL,
> > },
> > +[AV_PIX_FMT_GRAYF32BE] = {
> > +.name = "grayf32be",
> > +.nb_components = 1,
> > +.log2_chroma_w = 0,
> > +.log2_chroma_h = 0,
> > +.comp = {
> > +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> > +},
> > +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
> > +.alias = "yf32be",
> > +},
> > +[AV_PIX_FMT_GRAYF32LE] = {
> > +.name = "grayf32le",
> > +.nb_components = 1,
> > +.log2_chroma_w = 0,
> > +.log2_chroma_h = 0,
> > +.comp = {
> > +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> > +},
> > +.flags = AV_PIX_FMT_FLAG_FLOAT,
> > +.alias = "yf32le",
> > +},
> > };
> > #if FF_API_PLUS1_MINUS1
> > FF_ENABLE_DEPRECATION_WARNINGS
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 2b3307845e..7b254732d8 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -337,6 +337,9 @@ enum AVPixelFormat {
> > AV_PIX_FMT_GRAY14BE, /// > AV_PIX_FMT_GRAY14LE, /// >
> > +AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp,
> big-endian
> > +AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
> little-endian
> > +
> > AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS
> if you want to link with shared libav* because the number of formats might
> differ between versions
> > };
> >
> > @@ -405,6 +408,8 @@ enum AVPixelFormat {
> > #define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
> > #define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
> >
> > +#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
> > +
> > #define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
> > #define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
> > #define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index 44bdebdc93..5205c5bc60 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
>
> > @@ -79,7 +79,7 @@
> > */
> >
> > #define LIBAVUTIL_VERSION_MAJOR 56
> > -#define LIBAVUTIL_VERSION_MINOR 18
> > +#define LIBAVUTIL_VERSION_MINOR 19
> > #define LIBAVUTIL_VERSION_MICRO 102
>
> a bump to minor must reset micro to 100
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From 724f34ef9c551e7ac5af6f26840c3f2d3396eebd Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Fri, 3 Aug 2018 18:02:49 +0300
Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.
---
libavutil/pixdesc.c | 22 ++
libavutil/pixfmt.h | 5 +
libavutil/version.h | 4 ++--
tests/ref/fate/sws-pixdesc-query | 3 +++
4 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 96e079584a..970a83214c 100644
---
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Tue, Aug 07, 2018 at 12:17:58AM +0300, Sergey Lavrushkin wrote:
> I split patch to one for libavutil and another for libswscale,
> also added LUT for unscaled conversion, added
> conversions for scaling and updated fate tests.
> libavutil/pixdesc.c | 22 ++
> libavutil/pixfmt.h |5 +
> libavutil/version.h |2 +-
> tests/ref/fate/sws-pixdesc-query |3 +++
> 4 files changed, 31 insertions(+), 1 deletion(-)
> b58f328f5d90954c62957f127b1acbfad5795a4d
> 0004-libavutil-Adds-gray-floating-point-pixel-formats.patch
> From 8bcc10b49c41612b4d6549e64d90acf3f0b3fc6a Mon Sep 17 00:00:00 2001
> From: Sergey Lavrushkin
> Date: Fri, 3 Aug 2018 18:02:49 +0300
> Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.
>
> ---
> libavutil/pixdesc.c | 22 ++
> libavutil/pixfmt.h | 5 +
> libavutil/version.h | 2 +-
> tests/ref/fate/sws-pixdesc-query | 3 +++
> 4 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 96e079584a..970a83214c 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2206,6 +2206,28 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> .name = "opencl",
> .flags = AV_PIX_FMT_FLAG_HWACCEL,
> },
> +[AV_PIX_FMT_GRAYF32BE] = {
> +.name = "grayf32be",
> +.nb_components = 1,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
> +.alias = "yf32be",
> +},
> +[AV_PIX_FMT_GRAYF32LE] = {
> +.name = "grayf32le",
> +.nb_components = 1,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> +},
> +.flags = AV_PIX_FMT_FLAG_FLOAT,
> +.alias = "yf32le",
> +},
> };
> #if FF_API_PLUS1_MINUS1
> FF_ENABLE_DEPRECATION_WARNINGS
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 2b3307845e..7b254732d8 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -337,6 +337,9 @@ enum AVPixelFormat {
> AV_PIX_FMT_GRAY14BE, /// AV_PIX_FMT_GRAY14LE, ///
> +AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp,
> big-endian
> +AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
> little-endian
> +
> AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if
> you want to link with shared libav* because the number of formats might
> differ between versions
> };
>
> @@ -405,6 +408,8 @@ enum AVPixelFormat {
> #define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
> #define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
>
> +#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
> +
> #define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
> #define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
> #define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 44bdebdc93..5205c5bc60 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 56
> -#define LIBAVUTIL_VERSION_MINOR 18
> +#define LIBAVUTIL_VERSION_MINOR 19
> #define LIBAVUTIL_VERSION_MICRO 102
a bump to minor must reset micro to 100
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Tue, Aug 07, 2018 at 12:17:58AM +0300, Sergey Lavrushkin wrote:
> I split patch to one for libavutil and another for libswscale,
> also added LUT for unscaled conversion, added
> conversions for scaling and updated fate tests.
> libavutil/pixdesc.c | 22 ++
> libavutil/pixfmt.h |5 +
> libavutil/version.h |2 +-
> tests/ref/fate/sws-pixdesc-query |3 +++
> 4 files changed, 31 insertions(+), 1 deletion(-)
> b58f328f5d90954c62957f127b1acbfad5795a4d
> 0004-libavutil-Adds-gray-floating-point-pixel-formats.patch
> From 8bcc10b49c41612b4d6549e64d90acf3f0b3fc6a Mon Sep 17 00:00:00 2001
> From: Sergey Lavrushkin
> Date: Fri, 3 Aug 2018 18:02:49 +0300
> Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.
>
> ---
> libavutil/pixdesc.c | 22 ++
> libavutil/pixfmt.h | 5 +
> libavutil/version.h | 2 +-
> tests/ref/fate/sws-pixdesc-query | 3 +++
> 4 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 96e079584a..970a83214c 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2206,6 +2206,28 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> .name = "opencl",
> .flags = AV_PIX_FMT_FLAG_HWACCEL,
> },
> +[AV_PIX_FMT_GRAYF32BE] = {
> +.name = "grayf32be",
> +.nb_components = 1,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
> +.alias = "yf32be",
> +},
> +[AV_PIX_FMT_GRAYF32LE] = {
> +.name = "grayf32le",
> +.nb_components = 1,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> +},
> +.flags = AV_PIX_FMT_FLAG_FLOAT,
> +.alias = "yf32le",
> +},
> };
> #if FF_API_PLUS1_MINUS1
> FF_ENABLE_DEPRECATION_WARNINGS
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 2b3307845e..7b254732d8 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -337,6 +337,9 @@ enum AVPixelFormat {
> AV_PIX_FMT_GRAY14BE, /// AV_PIX_FMT_GRAY14LE, ///
> +AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp,
> big-endian
> +AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
> little-endian
> +
> AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if
> you want to link with shared libav* because the number of formats might
> differ between versions
> };
>
> @@ -405,6 +408,8 @@ enum AVPixelFormat {
> #define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
> #define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
>
> +#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
> +
> #define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
> #define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
> #define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 44bdebdc93..5205c5bc60 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 56
> -#define LIBAVUTIL_VERSION_MINOR 18
> +#define LIBAVUTIL_VERSION_MINOR 19
> #define LIBAVUTIL_VERSION_MICRO 102
>
> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> diff --git a/tests/ref/fate/sws-pixdesc-query
> b/tests/ref/fate/sws-pixdesc-query
> index 8071ec484d..451c7d83b9 100644
> --- a/tests/ref/fate/sws-pixdesc-query
> +++ b/tests/ref/fate/sws-pixdesc-query
> @@ -126,6 +126,7 @@ isBE:
>gray14be
>gray16be
>gray9be
> + grayf32be
>nv20be
>p010be
>p016be
> @@ -412,6 +413,8 @@ Gray:
>gray16le
>gray9be
>gray9le
> + grayf32be
> + grayf32le
>ya16be
>ya16le
>ya8
> --
> 2.14.1
>
> libswscale/input.c | 38 +++
> libswscale/output.c | 60
> +++
> libswscale/ppc/swscale_altivec.c |1
> libswscale/swscale_internal.h|9
> libswscale/swscale_unscaled.c| 54 ++-
> libswscale/utils.c | 20 +-
> libswscale/x86/swscale_template.c|3 +
> tests/ref/fate/filter-pixdesc-grayf32be |1
> tests/ref/fate/filter-pixdesc-grayf32le |1
> tests/ref/fate/filter-pixfmts-copy |2 +
> tests/ref/fate/filter-pixfmts-crop |2 +
> tests/ref/fate/filter-pixfmts-field |2 +
>
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
I split patch to one for libavutil and another for libswscale,
also added LUT for unscaled conversion, added
conversions for scaling and updated fate tests.
From 8bcc10b49c41612b4d6549e64d90acf3f0b3fc6a Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Fri, 3 Aug 2018 18:02:49 +0300
Subject: [PATCH 4/9] libavutil: Adds gray floating-point pixel formats.
---
libavutil/pixdesc.c | 22 ++
libavutil/pixfmt.h | 5 +
libavutil/version.h | 2 +-
tests/ref/fate/sws-pixdesc-query | 3 +++
4 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 96e079584a..970a83214c 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2206,6 +2206,28 @@ static const AVPixFmtDescriptor av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
.name = "opencl",
.flags = AV_PIX_FMT_FLAG_HWACCEL,
},
+[AV_PIX_FMT_GRAYF32BE] = {
+.name = "grayf32be",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+.alias = "yf32be",
+},
+[AV_PIX_FMT_GRAYF32LE] = {
+.name = "grayf32le",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+.alias = "yf32le",
+},
};
#if FF_API_PLUS1_MINUS1
FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 2b3307845e..7b254732d8 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -337,6 +337,9 @@ enum AVPixelFormat {
AV_PIX_FMT_GRAY14BE, ///
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
Hi On Sat, Aug 04, 2018 at 01:17:53AM +0300, Sergey Lavrushkin wrote: > 2018-08-04 0:11 GMT+03:00 Michael Niedermayer : > > > On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote: > > > 2018-08-03 16:07 GMT+03:00 Michael Niedermayer : > > > > > > > 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 destpointer 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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
Sergey Lavrushkin wrote: >2018-08-03 16:07 GMT+03:00 Michael Niedermayer >: [...] >>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. I am not surprised. In my experience, LUTs are often the faster solution. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-04 0:11 GMT+03:00 Michael Niedermayer :
> On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote:
> > 2018-08-03 16:07 GMT+03:00 Michael Niedermayer :
> >
> > > 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. 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.
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 destpointer to the output plane. For >8-bit
*output, this is in uint16_t
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?
> [...]
> > > +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
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On Fri, Aug 03, 2018 at 10:33:00PM +0300, Sergey Lavrushkin wrote:
> 2018-08-03 16:07 GMT+03:00 Michael Niedermayer :
>
> > 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
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-03 16:07 GMT+03:00 Michael Niedermayer :
> 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.
> > 5 files changed, 90 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> > index 96e079584a..7d307d9120 100644
> > --- a/libavutil/pixdesc.c
> > +++ b/libavutil/pixdesc.c
> > @@ -2198,6 +2198,28 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> > .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_ALPHA |
> > AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_FLOAT,
> > },
> > +[AV_PIX_FMT_GRAYF32BE] = {
> > +.name = "grayf32be",
> > +.nb_components = 1,
> > +.log2_chroma_w = 0,
> > +.log2_chroma_h = 0,
> > +.comp = {
> > +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> > +},
> > +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
> > +.alias = "yf32be",
> > +},
> > +[AV_PIX_FMT_GRAYF32LE] = {
> > +.name = "grayf32le",
> > +.nb_components = 1,
> > +.log2_chroma_w = 0,
> > +.log2_chroma_h = 0,
> > +.comp = {
> > +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> > +},
> > +.flags = AV_PIX_FMT_FLAG_FLOAT,
> > +.alias = "yf32le",
> > +},
> > [AV_PIX_FMT_DRM_PRIME] = {
> > .name = "drm_prime",
> > .flags = AV_PIX_FMT_FLAG_HWACCEL,
>
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 2b3307845e..aa9a4f60c1 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -320,6 +320,9 @@ enum AVPixelFormat {
> > AV_PIX_FMT_GBRAPF32BE, ///< IEEE-754 single precision planar GBRA
> 4:4:4:4, 128bpp, big-endian
> > AV_PIX_FMT_GBRAPF32LE, ///< IEEE-754 single precision planar GBRA
> 4:4:4:4, 128bpp, little-endian
> >
> > +AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp,
> big-endian
> > +AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
> little-endian
> > +
> > /**
> > * DRM-managed buffers exposed through PRIME buffer sharing.
> > *
>
> new enum values can only be added in such a way that no value of an
> existing
> enum changes. This would change the value of the following enums
Ok.
> @@ -405,6 +408,8 @@ enum AVPixelFormat {
> > #define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
> > #define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
> >
> > +#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
> > +
> > #define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
> > #define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
> > #define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
> > diff --git a/libswscale/swscale_internal.h
> b/libswscale/swscale_internal.h
> > index 1703856ab2..4a2cdfe658 100644
> > --- a/libswscale/swscale_internal.h
> > +++ b/libswscale/swscale_internal.h
> > @@ -764,6 +764,13 @@ static av_always_inline int isAnyRGB(enum
> AVPixelFormat pix_fmt)
> > pix_fmt == AV_PIX_FMT_MONOBLACK || pix_fmt ==
> AV_PIX_FMT_MONOWHITE;
> > }
> >
> > +static av_always_inline int isFloat(enum AVPixelFormat pix_fmt)
> > +{
> > +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> > +av_assert0(desc);
> > +return desc->flags & AV_PIX_FMT_FLAG_FLOAT;
> > +}
> > +
> > static av_always_inline int isALPHA(enum AVPixelFormat pix_fmt)
> > {
> > const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
>
> > diff --git a/libswscale/swscale_unscaled.c
> b/libswscale/swscale_unscaled.c
> > index 6480070cbf..f5b4c9be9d 100644
> > ---
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
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
also fate tests need an update, (make fate) fails otherwise, the update should
be part of the patch that causes the failure otherwise
> 5 files changed, 90 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 96e079584a..7d307d9120 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2198,6 +2198,28 @@ static const AVPixFmtDescriptor
> av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_ALPHA |
> AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_FLOAT,
> },
> +[AV_PIX_FMT_GRAYF32BE] = {
> +.name = "grayf32be",
> +.nb_components = 1,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> +},
> +.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
> +.alias = "yf32be",
> +},
> +[AV_PIX_FMT_GRAYF32LE] = {
> +.name = "grayf32le",
> +.nb_components = 1,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
> +},
> +.flags = AV_PIX_FMT_FLAG_FLOAT,
> +.alias = "yf32le",
> +},
> [AV_PIX_FMT_DRM_PRIME] = {
> .name = "drm_prime",
> .flags = AV_PIX_FMT_FLAG_HWACCEL,
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 2b3307845e..aa9a4f60c1 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -320,6 +320,9 @@ enum AVPixelFormat {
> AV_PIX_FMT_GBRAPF32BE, ///< IEEE-754 single precision planar GBRA
> 4:4:4:4, 128bpp, big-endian
> AV_PIX_FMT_GBRAPF32LE, ///< IEEE-754 single precision planar GBRA
> 4:4:4:4, 128bpp, little-endian
>
> +AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp,
> big-endian
> +AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
> little-endian
> +
> /**
> * DRM-managed buffers exposed through PRIME buffer sharing.
> *
new enum values can only be added in such a way that no value of an existing
enum changes. This would change the value of the following enums
> @@ -405,6 +408,8 @@ enum AVPixelFormat {
> #define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
> #define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
>
> +#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
> +
> #define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
> #define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
> #define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
> index 1703856ab2..4a2cdfe658 100644
> --- a/libswscale/swscale_internal.h
> +++ b/libswscale/swscale_internal.h
> @@ -764,6 +764,13 @@ static av_always_inline int isAnyRGB(enum AVPixelFormat
> pix_fmt)
> pix_fmt == AV_PIX_FMT_MONOBLACK || pix_fmt ==
> AV_PIX_FMT_MONOWHITE;
> }
>
> +static av_always_inline int isFloat(enum AVPixelFormat pix_fmt)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> +av_assert0(desc);
> +return desc->flags & AV_PIX_FMT_FLAG_FLOAT;
> +}
> +
> static av_always_inline int isALPHA(enum AVPixelFormat pix_fmt)
> {
> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> index 6480070cbf..f5b4c9be9d 100644
> --- a/libswscale/swscale_unscaled.c
> +++ b/libswscale/swscale_unscaled.c
> @@ -1467,6 +1467,46 @@ static int yvu9ToYv12Wrapper(SwsContext *c, const
> uint8_t *src[],
> return srcSliceH;
> }
>
> +static int uint_y_to_float_y_wrapper(SwsContext *c, const uint8_t *src[],
> + int srcStride[], int srcSliceY,
> + int srcSliceH, uint8_t *dst[], int
> dstStride[])
> +{
> +int y, x;
> +int dstStrideFloat = dstStride[0] >> 2;;
theres a ; too much
also newly added strides should probably be ptrdiff_t
> +const uint8_t *srcPtr = src[0];
> +float *dstPtr = (float *)(dst[0] + dstStride[0] * srcSliceY);
> +
> +
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
2018-08-02 20:52 GMT+02:00, Sergey Lavrushkin : > 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? I would have expected the conversion to be from and to GRAY16, is this simply a wrong assumption? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
On 8/2/2018 4:22 PM, Martin Vignali wrote:
>>
>> +static int uint_y_to_float_y_wrapper(SwsContext *c, const uint8_t *src[],
>> + int srcStride[], int srcSliceY,
>> + int srcSliceH, uint8_t *dst[], int
>> dstStride[])
>> +{
>> +int y, x;
>> +int dstStrideFloat = dstStride[0] >> 2;;
>> +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;
>> +}
>> +srcPtr += srcStride[0];
>> +dstPtr += dstStrideFloat;
>> +}
>> +
>> +return srcSliceH;
>> +}
>> +
>> +static int float_y_to_uint_y_wrapper(SwsContext *c, const uint8_t* src[],
>> + int srcStride[], int srcSliceY,
>> + int srcSliceH, uint8_t* dst[], int
>> dstStride[])
>> +{
>> +int y, x;
>> +int srcStrideFloat = srcStride[0] >> 2;
>> +const float *srcPtr = (const float *)src[0];
>> +uint8_t *dstPtr = dst[0] + dstStride[0] * srcSliceY;
>> +
>> +for (y = 0; y < srcSliceH; ++y){
>> +for (x = 0; x < c->srcW; ++x){
>> +dstPtr[x] = (uint8_t)(255.0f * FFMIN(FFMAX(srcPtr[x], 0.0f),
>> 1.0f));
>> +}
>> +srcPtr += srcStrideFloat;
>> +dstPtr += dstStride[0];
>> +}
>> +
>> +return srcSliceH;
>> +}
>>
>
>
> Maybe you can avoid to use float for these conversions
> like in libavcodec/exr.c, where there is a float to uint16 conversion
>
> Martin
Unless i'm missing something, I think the point is that he was asked to
not do format conversion within the filter itself.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
>
> +static int uint_y_to_float_y_wrapper(SwsContext *c, const uint8_t *src[],
> + int srcStride[], int srcSliceY,
> + int srcSliceH, uint8_t *dst[], int
> dstStride[])
> +{
> +int y, x;
> +int dstStrideFloat = dstStride[0] >> 2;;
> +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;
> +}
> +srcPtr += srcStride[0];
> +dstPtr += dstStrideFloat;
> +}
> +
> +return srcSliceH;
> +}
> +
> +static int float_y_to_uint_y_wrapper(SwsContext *c, const uint8_t* src[],
> + int srcStride[], int srcSliceY,
> + int srcSliceH, uint8_t* dst[], int
> dstStride[])
> +{
> +int y, x;
> +int srcStrideFloat = srcStride[0] >> 2;
> +const float *srcPtr = (const float *)src[0];
> +uint8_t *dstPtr = dst[0] + dstStride[0] * srcSliceY;
> +
> +for (y = 0; y < srcSliceH; ++y){
> +for (x = 0; x < c->srcW; ++x){
> +dstPtr[x] = (uint8_t)(255.0f * FFMIN(FFMAX(srcPtr[x], 0.0f),
> 1.0f));
> +}
> +srcPtr += srcStrideFloat;
> +dstPtr += dstStride[0];
> +}
> +
> +return srcSliceH;
> +}
>
Maybe you can avoid to use float for these conversions
like in libavcodec/exr.c, where there is a float to uint16 conversion
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.
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 +++-
5 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 96e079584a..7d307d9120 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2198,6 +2198,28 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
.flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_ALPHA |
AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_FLOAT,
},
+[AV_PIX_FMT_GRAYF32BE] = {
+.name = "grayf32be",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_FLOAT,
+.alias = "yf32be",
+},
+[AV_PIX_FMT_GRAYF32LE] = {
+.name = "grayf32le",
+.nb_components = 1,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 0, 32, 3, 31, 1 }, /* Y */
+},
+.flags = AV_PIX_FMT_FLAG_FLOAT,
+.alias = "yf32le",
+},
[AV_PIX_FMT_DRM_PRIME] = {
.name = "drm_prime",
.flags = AV_PIX_FMT_FLAG_HWACCEL,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 2b3307845e..aa9a4f60c1 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -320,6 +320,9 @@ enum AVPixelFormat {
AV_PIX_FMT_GBRAPF32BE, ///< IEEE-754 single precision planar GBRA 4:4:4:4,
128bpp, big-endian
AV_PIX_FMT_GBRAPF32LE, ///< IEEE-754 single precision planar GBRA 4:4:4:4,
128bpp, little-endian
+AV_PIX_FMT_GRAYF32BE, ///< IEEE-754 single precision Y, 32bpp, big-endian
+AV_PIX_FMT_GRAYF32LE, ///< IEEE-754 single precision Y, 32bpp,
little-endian
+
/**
* DRM-managed buffers exposed through PRIME buffer sharing.
*
@@ -405,6 +408,8 @@ enum AVPixelFormat {
#define AV_PIX_FMT_GBRPF32AV_PIX_FMT_NE(GBRPF32BE, GBRPF32LE)
#define AV_PIX_FMT_GBRAPF32 AV_PIX_FMT_NE(GBRAPF32BE, GBRAPF32LE)
+#define AV_PIX_FMT_GRAYF32 AV_PIX_FMT_NE(GRAYF32BE, GRAYF32LE)
+
#define AV_PIX_FMT_YUVA420P9 AV_PIX_FMT_NE(YUVA420P9BE , YUVA420P9LE)
#define AV_PIX_FMT_YUVA422P9 AV_PIX_FMT_NE(YUVA422P9BE , YUVA422P9LE)
#define AV_PIX_FMT_YUVA444P9 AV_PIX_FMT_NE(YUVA444P9BE , YUVA444P9LE)
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 1703856ab2..4a2cdfe658 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -764,6 +764,13 @@ static av_always_inline int isAnyRGB(enum AVPixelFormat
pix_fmt)
pix_fmt == AV_PIX_FMT_MONOBLACK || pix_fmt == AV_PIX_FMT_MONOWHITE;
}
+static av_always_inline int isFloat(enum AVPixelFormat pix_fmt)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
+av_assert0(desc);
+return desc->flags & AV_PIX_FMT_FLAG_FLOAT;
+}
+
static av_always_inline int isALPHA(enum AVPixelFormat pix_fmt)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 6480070cbf..f5b4c9be9d 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1467,6 +1467,46 @@ static int yvu9ToYv12Wrapper(SwsContext *c, const
uint8_t *src[],
return srcSliceH;
}
+static int uint_y_to_float_y_wrapper(SwsContext *c, const uint8_t *src[],
+ int srcStride[], int srcSliceY,
+ int srcSliceH, uint8_t *dst[], int
dstStride[])
+{
+int y, x;
+int dstStrideFloat = dstStride[0] >> 2;;
+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;
+}
+srcPtr += srcStride[0];
+dstPtr += dstStrideFloat;
+}
+
+return srcSliceH;
+}
+
+static int float_y_to_uint_y_wrapper(SwsContext *c, const uint8_t* src[],
+ int srcStride[], int srcSliceY,
+ int srcSliceH, uint8_t* dst[], int
dstStride[])
+{
+int y, x;
+int srcStrideFloat = srcStride[0] >> 2;
+const float *srcPtr = (const float *)src[0];
+uint8_t *dstPtr = dst[0] + dstStride[0] * srcSliceY;
+
+for (y = 0; y < srcSliceH; ++y){
+for (x = 0; x < c->srcW; ++x){
+dstPtr[x] =
