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] Documentation for sr filter
Sorry, I accidentally sent previous patch, here is updated version.
From 99afeefe4add5b932140388f48ec4111734aa593 Mon Sep 17 00:00:00 2001
From: Sergey Lavrushkin
Date: Fri, 3 Aug 2018 17:24:00 +0300
Subject: [PATCH 9/9] doc/filters.texi: Adds documentation for sr filter.
---
doc/filters.texi | 60
1 file changed, 60 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0b0903e5a7..9995ca532b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15394,6 +15394,66 @@ option may cause flicker since the B-Frames have often larger QP. Default is
@code{0} (not enabled).
@end table
+@section sr
+
+Scale the input by applying one of the super-resolution methods based on
+convolutional neural networks.
+
+Training scripts as well as scripts for model generation are provided in
+the repository @url{https://github.com/HighVoltageRocknRoll/sr.git}.
+
+The filter accepts the following options:
+
+@table @option
+@item model
+Specify which super-resolution model to use. This option accepts the following values:
+
+@table @samp
+@item srcnn
+Super-Resolution Convolutional Neural Network model
+@url{https://arxiv.org/abs/1501.00092}.
+
+@item espcn
+Efficient Sub-Pixel Convolutional Neural Network model
+@url{https://arxiv.org/abs/1609.05158}.
+
+@end table
+
+Default value is @samp{srcnn}.
+
+@item dnn_backend
+Specify which DNN backend to use for model loading and execution. This option accepts
+the following values:
+
+@table @samp
+@item native
+Native implementation of DNN loading and execution.
+
+@item tensorflow
+TensorFlow backend @url{https://www.tensorflow.org/}. To enable this backend you
+need to install the TensorFlow for C library (see
+@url{https://www.tensorflow.org/install/install_c}) and configure FFmpeg with
+@code{--enable-libtensorflow}
+
+@end table
+
+Default value is @samp{native}.
+
+@item scale_factor
+Set scale factor for SRCNN model, for which custom model file was provided.
+Allowed values are @code{2}, @code{3} and @code{4}. Scale factor is necessary
+for SRCNN model, because it accepts input upscaled using bicubic upscaling with
+proper scale factor.
+
+Default value is @code{2}.
+
+@item model_filename
+Set path to model file specifying network architecture and its parameters.
+Note that different backends use different file formats. If path to model
+file is not specified, built-in models for 2x upscaling are used.
+
+@end table
+
@anchor{subtitles}
@section subtitles
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][RFC][PATCH] avcodec: add IMM4 decoder
On Sat, 11 Aug 2018 at 13:24, Paul B Mahol wrote: > Hi, > > Much improved and cleaned up version attached. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > +INIT_VLC_SPARSE_STATIC(_tab, 9, FF_ARRAY_ELEMS(cbplo_bits), > + cbplo_bits, 1, 1, cbplo_codes, 1, 1, > cbplo_symbols, 1, 1, 512); > + > +INIT_VLC_SPARSE_STATIC(_tab, 6, FF_ARRAY_ELEMS(cbphi_bits), > + cbphi_bits, 1, 1, cbphi_codes, 1, 1, NULL, 0, 0, > 64); > + > +INIT_VLC_SPARSE_STATIC(_tab, 9, FF_ARRAY_ELEMS(blktype_bits), > + blktype_bits, 1, 1, blktype_codes, 1, 1, > blktype_symbols, 1, 1, 512); > + > +INIT_VLC_SPARSE_STATIC(_tab, 12, FF_ARRAY_ELEMS(block_bits), > + block_bits, 1, 1, block_codes, 1, 1, > block_symbols, 2, 2, 4096); Don't you need to wrap this in a separate init function and call it from ff_thread_once()? I'd prefer if you just put cbplo_tab inside the main context, but I don't mind them being global. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Check in decode_tiles() if there is data remaining
Hi, On Sat, Aug 11, 2018 at 6:55 AM, Michael Niedermayer wrote: > But if you still want a flag, i can add one for vp9. > That would be great, thank you for your consideration. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP][RFC][PATCH] avcodec: add IMM4 decoder
Hi, Much improved and cleaned up version attached. 0001-avcodec-add-IMM4-decoder.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vp9: Check in decode_tiles() if there is data remaining
On Fri, Aug 10, 2018 at 10:41:21PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Aug 10, 2018 at 6:54 PM, Michael Niedermayer > wrote:
>
> > On Fri, Aug 10, 2018 at 02:16:56AM -0400, Ronald S. Bultje wrote:
> > > My objection:
> > > if a file has exactly symbols of 8 bits in arithdata, then after all
> > this,
> > > the arithcoder will signal empty and EOF, even though no error occured.
> > > Imagine a bitcoder (non-arith) of this situation.
> > [..]
> > > After get_bits(gb, 8),
> > > the data pointer will have reached the end, and the bits_left is 0, but
> > > that does not indicate an error, quite the contrary. It just means that
> > the
> > > byte boundary happened to align with the exact end of the file. This can
> > > happen.
> >
> > Yes but thats not something we do with bitcoders.
> > bits_left being 0 does indicate an error when the next
> > step unconditionally reads 1 or more bits.
> > The same was the intend of the patch here, check if the end was reached
> > before more reads.
> > vp56_rac_renorm() always reads data if(bits >= 0 && c->buffer < c->end)
> >
> > I had thought that will get executed in all cases, i may have missed
> > something and the check should be moved by a few lines
>
>
> For example, you're checking the arithcoder in pass=2 also, but no
> bitstream reading occurs in that pass...
this is what i meant by "should be moved by a few lines"
that is as in here:
@@ -1306,6 +1306,9 @@ static int decode_tiles(AVCodecContext *avctx,
decode_sb_mem(td, row, col, lflvl_ptr,
yoff2, uvoff2, BL_64X64);
} else {
+if (td->c->end <= td->c->buffer && td->c->bits >= 0) {
+return AVERROR_INVALIDDATA;
+}
decode_sb(td, row, col, lflvl_ptr,
yoff2, uvoff2, BL_64X64);
>
> > My suggestion:
> > > add an eof flag to the arithcoder. When we have reached the above
> > condition
> > > where new data is needed but not present, simply set the EOF flag, and
> > > check that for errors. If it's set, you can error out.
> >
> > This is possible but it will make the code likely slower as the reading
> > happens in a av_always_inline function which itself is used by several
> > av_always_inline functions. So this else context->flag = 1;
> > could end up being added to many points in the binary.
> >
> > I can do this of course if you prefer it just seems sub-optimal to me
> > unless you have some idea on how to do this without increasing the
> > complexity of the rac functions
>
>
> But it's an error branch, it is not normally executed. It just makes the
> binary a few bytes larger.
The condition has to be checked even if there is no error.
Currently the existing branch is a read vs no read check that combines
both the need to read and the end of buffer checks.
with the code to set the flag there would be 3 instead of 1
if (need to read)
if(space left)
do read
else
set flag
vs
if (need to read and space left)
do read
That means the condition is split in 2 branches instead of 1 and
theres a else
and this is one of the most inner and often executed functions
>
> Here's another way of looking at this, which isn't so much about exact
> bytes and instructions (which will all change in the noise range), but
> about code maintainability: you're likely going to want to do fixes like
> this for vp8, vp9, vp56, etc., and similar for users of other arithcoders
> like cabac or the multisymbol one in daala/av1 and so on. Each of these
> decoders are in and by themselves pretty complex creatures, and the people
> understanding what's going on under the hood are few and far between, and
> half of them are no longer active. I'm not saying you're not intelligent,
> but I do think bugs like the one above can creep in because you're not
> intimately familiar with all bells and whistles in each decoder codebase.
> That being true, a case could be made that noise-range changes in
> instruction count or byte size is less important than ease of maintenance.
Of course iam not intimately familiar with every decoder. Noone is or could
be. But still ive found this pass=2 bug you talk about before you mentioned
"pass 2" the first time. So either you saw it before and did not mentioning
it directly (which sort of makes your reviews not that usefull)
or your review is just making us find bugs by randomly poking each other.
And Of course changing the code slightly leads to noise in benchmarks.
But the point is that adding operations in inner loops makes them more
complex thus slower on average. turning a single if() into a nested
if() if/else will make the code slower except by chance of the noise.
Also not only is there more code in the path exeucted. There is more
pressure on the code cache (which is small) as it needs to hold also
some of the not
[FFmpeg-devel] [PATCH] lavc/pthread: use THREAD_SAFE_CALLBACKS() to simplifx more code
use THREAD_SAFE_CALLBACKS() to simplifx more code
Signed-off-by: Jun Zhao
---
libavcodec/pthread_frame.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 5104b1b..36ac0ac 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -908,8 +908,7 @@ static int thread_get_buffer_internal(AVCodecContext
*avctx, ThreadFrame *f, int
}
pthread_mutex_lock(>parent->buffer_mutex);
-if (avctx->thread_safe_callbacks ||
-avctx->get_buffer2 == avcodec_default_get_buffer2) {
+if (THREAD_SAFE_CALLBACKS(avctx)) {
err = ff_get_buffer(avctx, f->f, flags);
} else {
pthread_mutex_lock(>progress_mutex);
@@ -976,8 +975,7 @@ void ff_thread_release_buffer(AVCodecContext *avctx,
ThreadFrame *f)
FrameThreadContext *fctx;
AVFrame *dst, *tmp;
int can_direct_free = !(avctx->active_thread_type & FF_THREAD_FRAME) ||
- avctx->thread_safe_callbacks ||
- avctx->get_buffer2 == avcodec_default_get_buffer2;
+ THREAD_SAFE_CALLBACKS(avctx);
if (!f->f || !f->f->buf[0])
return;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
