Re: [FFmpeg-devel] [PATCH] avfilter/vf_unsharp: enable slice threading

2019-05-10 Thread Song, Ruiling
> -Original Message-
> From: Song, Ruiling
> Sent: Thursday, May 9, 2019 3:43 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling 
> Subject: [PATCH] avfilter/vf_unsharp: enable slice threading
> 
> Signed-off-by: Ruiling Song 
> ---
>  libavfilter/unsharp.h|  4 +-
>  libavfilter/vf_unsharp.c | 98 ++--
>  2 files changed, 78 insertions(+), 24 deletions(-)

Add some performance number in case somebody have interest to know.
Running "ffmpeg -i 1080p.mp4 -vf unsharp=la=3:ca=3 -an -f null /dev/null" on my 
local machine (i7-6770HQ): the fps increase from 50 to 120.

Thanks!
Ruiling
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCHv2] lavfi: add gblur_opencl filter

2019-05-08 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Dylan Fernando
> Sent: Tuesday, May 7, 2019 8:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCHv2] lavfi: add gblur_opencl filter
> 
> Anyone have any comments/feedback?
I think unsharp_opencl with a negative amount should do similar thing as this 
one.
What's the difference? Better quality? or better speed?

Thanks!
Ruiling
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V3] lavfi/opencl: add nlmeans_opencl filter

2019-05-20 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, May 21, 2019 6:16 AM
> To: 'FFmpeg development discussions and patches'  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V3] lavfi/opencl: add nlmeans_opencl
> filter
> 
> On 20/05/2019 02:18, Song, Ruiling wrote:
> >> -----Original Message-
> >> From: Song, Ruiling
> >> Sent: Monday, May 13, 2019 10:18 AM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>; 'Mark Thompson' 
> >> Subject: RE: [FFmpeg-devel] [PATCH V3] lavfi/opencl: add
> nlmeans_opencl
> >> filter
> >>
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >>> Of Ruiling Song
> >>> Sent: Tuesday, May 7, 2019 10:45 AM
> >>> To: ffmpeg-devel@ffmpeg.org
> >>> Cc: Song, Ruiling 
> >>> Subject: [FFmpeg-devel] [PATCH V3] lavfi/opencl: add nlmeans_opencl
> >> filter
> >>>
> >>> Signed-off-by: Ruiling Song 
> >>> ---
> >>>  configure   |   1 +
> >>>  doc/filters.texi|   4 +
> >>>  libavfilter/Makefile|   1 +
> >>>  libavfilter/allfilters.c|   1 +
> >>>  libavfilter/opencl/nlmeans.cl   | 115 +
> >>>  libavfilter/opencl_source.h |   1 +
> >>>  libavfilter/vf_nlmeans_opencl.c | 443
> >>> 
> >>>  7 files changed, 566 insertions(+)
> >>>  create mode 100644 libavfilter/opencl/nlmeans.cl
> >>>  create mode 100644 libavfilter/vf_nlmeans_opencl.c
> >> Hi Mark,
> >>
> >> Do you have further comment on v3?
> > Will apply if no further comments.
> 
> No more from me.  I also did some testing of this on Mali, all good.
Thanks Mark for your valuable comments on the patch, will apply.

> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

2019-05-06 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, May 6, 2019 10:20 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl filter
> 
> On 29/04/2019 03:06, Song, Ruiling wrote:>
> > In order to verify the patch, I also have more testing on the CPU OpenCL
> driver from Intel.
> > I make it run 100 times, and still not see any reported overflow. So I think
> we can say the filter is in good quality to be merged. Any different idea?
> 
> I've tried a lot more times on some additional platforms (Skylake-GT3, Mali-
> G52) and I can't reproduce it on anything else.  So, I think I agree that it 
> must
> be a driver issue and shouldn't block anything.
> 
> 
> On 12/04/2019 16:09, Ruiling Song wrote:
> > Signed-off-by: Ruiling Song 
> > ---
> >  configure   |   1 +
> >  doc/filters.texi|   4 +
> >  libavfilter/Makefile|   1 +
> >  libavfilter/allfilters.c|   1 +
> >  libavfilter/opencl/nlmeans.cl   | 115 +
> >  libavfilter/opencl_source.h |   1 +
> >  libavfilter/vf_nlmeans_opencl.c | 442
> 
> >  7 files changed, 565 insertions(+)
> >  create mode 100644 libavfilter/opencl/nlmeans.cl
> >  create mode 100644 libavfilter/vf_nlmeans_opencl.c
> >
> > ...
> > +
> > +static int nlmeans_plane(AVFilterContext *avctx, cl_mem dst, cl_mem src,
> > + cl_int width, cl_int height, cl_int p, cl_int r)
> > +{
> > +NLMeansOpenCLContext *ctx = avctx->priv;
> > +const float zero = 0.0f;
> > +const size_t worksize1[] = {height};
> > +const size_t worksize2[] = {width};
> > +const size_t worksize3[2] = {width, height};
> > +int dx, dy, err = 0, weight_buf_size;
> > +cl_int cle;
> > +int nb_pixel, *tmp, idx = 0;
> > +cl_int *dxdy;
> > +
> > +weight_buf_size = width * height * sizeof(float);
> > +cle = clEnqueueFillBuffer(ctx->command_queue, ctx->weight,
> > +  , sizeof(float), 0, weight_buf_size,
> > +  0, NULL, NULL);
> > +CL_FAIL_ON_ERROR(AVERROR(EIO), "Failed to fill weight buffer: %d.\n",
> > + cle);
> > +cle = clEnqueueFillBuffer(ctx->command_queue, ctx->sum,
> > +  , sizeof(float), 0, weight_buf_size,
> > +  0, NULL, NULL);
> > +CL_FAIL_ON_ERROR(AVERROR(EIO), "Failed to fill sum buffer: %d.\n",
> > + cle);
> > +
> > +nb_pixel = (2 * r + 1) * (2 * r + 1) - 1;
> > +dxdy = av_malloc(nb_pixel * 2 * sizeof(cl_int));
> > +tmp = av_malloc(nb_pixel * 2 * sizeof(int));
> > +
> > +if (!dxdy || !tmp)
> > +goto fail;
> > +
> > +for (dx = -r; dx <= r; dx++) {
> > +for (dy = -r; dy <= r; dy++) {
> > +if (dx || dy) {
> > +tmp[idx++] = dx;
> > +tmp[idx++] = dy;
> > +}
> > +}
> > +}
> > +// repack dx/dy seperately, as we want to do four pairs of dx/dy in a
> batch
> > +for (int i = 0; i < nb_pixel / 4; i++) {
> > +dxdy[i * 8] = tmp[i * 8]; // dx0
> > +dxdy[i * 8 + 1] = tmp[i * 8 + 2]; // dx1
> > +dxdy[i * 8 + 2] = tmp[i * 8 + 4]; // dx2
> > +dxdy[i * 8 + 3] = tmp[i * 8 + 6]; // dx3
> > +dxdy[i * 8 + 4] = tmp[i * 8 + 1]; // dy0
> > +dxdy[i * 8 + 5] = tmp[i * 8 + 3]; // dy1
> > +dxdy[i * 8 + 6] = tmp[i * 8 + 5]; // dy2
> > +dxdy[i * 8 + 7] = tmp[i * 8 + 7]; // dy3
> > +}
> > +av_freep();
> > +
> > +for (int i = 0; i < nb_pixel / 4; i++) {
> > +int *dx_cur = dxdy + 8 * i;
> > +int *dy_cur = dxdy + 8 * i + 4;
> 
> cl_int.
Fixed
> 
> > +
> > +// horizontal pass
> > +// integral(x,y) = sum([u(v,y) - u(v+dx,y+dy)]^2) for v in [0, x]
> > +CL_SET_KERNEL_ARG(ctx->horiz_kernel, 0, cl_mem, 
> >integral_img);
> > +CL_SET_KERNEL_ARG(ctx->horiz_kernel, 1, cl_mem, );
> > +CL_SET_KERNEL_ARG(ctx->horiz_kernel, 2, cl_int, );
> > +CL_SET_KERNEL_ARG(ctx->horiz_kernel, 3, cl_int, );
> > +CL_SET_KERNEL_ARG(ctx->horiz_kernel, 4, cl_int4, dx_cur);
> > +CL_SET_KERNEL_ARG(ctx->horiz_kernel, 5, cl_int4, dy_

Re: [FFmpeg-devel] [PATCH] lavfi/gblur: doing several columns at the same time

2019-05-06 Thread Song, Ruiling


> -Original Message-
> From: Paul B Mahol [mailto:one...@gmail.com]
> Sent: Monday, May 6, 2019 4:02 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Song, Ruiling 
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi/gblur: doing several columns at
> the same time
> 
> On 5/6/19, Ruiling Song  wrote:
> > Instead of doing each column one by one, doing several columns
> > together gives about 30% better performance.
> >
> > Signed-off-by: Ruiling Song 
> > ---
> > below is some of performance numbers(fps) on my i7-6770HQ (decode +
> gblur):
> >
> > resolution:480p | 720p | 1080p | 4k
> > without patch: 393  | 146  | 71| 14
> > with patch:502  | 184  | 95| 18
> >  libavfilter/vf_gblur.c | 62 --
> >  1 file changed, 42 insertions(+), 20 deletions(-)
> >
> 
> LGTM
Thanks Paul, will apply. 

Ruiling
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

2019-04-28 Thread Song, Ruiling


> -Original Message-
> From: Song, Ruiling
> Sent: Tuesday, April 23, 2019 4:52 PM
> To: 'FFmpeg development discussions and patches'  de...@ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl filter
> 
> 
> 
> > -Original Message-
> > From: Song, Ruiling
> > Sent: Sunday, April 21, 2019 8:18 PM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > nlmeans_opencl filter
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf Of
> > > Mark Thompson
> > > Sent: Saturday, April 20, 2019 11:08 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > nlmeans_opencl
> > > filter
> > >
> > > On 17/04/2019 03:43, Song, Ruiling wrote:
> > > >> -Original Message-
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of
> > > >> Mark Thompson
> > > >> Sent: Wednesday, April 17, 2019 5:28 AM
> > > >> To: ffmpeg-devel@ffmpeg.org
> > > >> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > > nlmeans_opencl
> > > >> filter
> > > >>
> > > >> On 12/04/2019 16:09, Ruiling Song wrote:
> > > >>> Signed-off-by: Ruiling Song 
> > > >>
> > > >> I can't work out where the problem is, but there is something really
> > weirdly
> > > >> nondeterministic going on here.
> > > >>
> > > >> E.g.
> > > >>
> > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-
> 120-
> > > mbps-
> > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > > >>
> >
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > > >> frames:v 10 -f framemd5 -
> > > >> ...
> > > >> 0,  0,  0,1, 12441600, 
> > > >> 8b8805818076b23ae6f80ec2b5a349d4
> > > >> 0,  1,  1,1, 12441600, 
> > > >> 7a7fdaa083dc337cfb6af31b643f30a3
> > > >> 0,  2,  2,1, 12441600, 
> > > >> b10ef2a1e5125cc67e262e086f8040b5
> > > >> 0,  3,  3,1, 12441600, 
> > > >> c06b53ad90e0357e537df41b63d5b1dc
> > > >> 0,  4,  4,1, 12441600, 
> > > >> 5aa2da07703859a3dee080847dd17d46
> > > >> 0,  5,  5,1, 12441600, 
> > > >> 733364c6be6af825057e905a6092937d
> > > >> 0,  6,  6,1, 12441600, 
> > > >> 47edae2dec956a582b04babb745d26b0
> > > >> 0,  7,  7,1, 12441600, 
> > > >> 4e45fe8268df4298d06a17ab8e46c3e9
> > > >> 0,  8,  8,1, 12441600, 
> > > >> 960d722a3f8787c9191299a114c04174
> > > >> 0,  9,  9,1, 12441600, 
> > > >> e759c07ee4834a9cf94bfcb4128e7612
> > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-
> 120-
> > > mbps-
> > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > > >>
> >
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > > >> frames:v 10 -f framemd5 -
> > > >> 0,  0,  0,1, 12441600, 
> > > >> 8b8805818076b23ae6f80ec2b5a349d4
> > > >> [Parsed_nlmeans_opencl_2 @ 0x5557ae580d00] integral image
> > overflow
> > > >> 2157538
> > > >> 0,  1,  1,1, 12441600, 
> > > >> bce72e10a9f1118940c5a8392ad78ec3
> > > >> 0,  2,  2,1, 12441600, 
> > > >> b10ef2a1e5125cc67e262e086f8040b5
> > > >> 0,  3,  3,1, 12441600, 
> > > >> c06b53ad90e0357e537df41b63d5b1dc
> > > >> 0,  4,  4,1, 12441600, 
> > > >> 5aa2da07703859a3dee080847dd17d46
> > > >> 0,  5,  5,1, 12441600, 
> > > >> 733364c6be6af825057e905a6092937d
> > > >> 0,  6,  6,1, 12441600, 

Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

2019-05-05 Thread Song, Ruiling
Will apply.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] lavc/libdavs2.c: optimize frame copy

2019-07-04 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of hwrenx
> Sent: Wednesday, July 3, 2019 11:24 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v1] lavc/libdavs2.c: optimize frame copy
> 

I think it's better to use "correct ..." or "fix ..." instead of "optimize" in 
the title.
Maybe a short commit message here would be useful for reviewer.

> Signed-off-by: hwrenx 
> ---
>  libavcodec/libdavs2.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index 218f3ec..15ed3a1 100644
> --- a/libavcodec/libdavs2.c
> +++ b/libavcodec/libdavs2.c
> @@ -62,7 +62,7 @@ static int davs2_dump_frames(AVCodecContext *avctx,
> davs2_picture_t *pic, int *g
>   davs2_seq_info_t *headerset, int ret_type, 
> AVFrame *frame)
>  {
>  DAVS2Context *cad= avctx->priv_data;
> -int bytes_per_sample = pic->bytes_per_sample;
> +int bytes_per_sample = pic->bytes_per_sample == 8 ? 1 : 2;
>  int plane = 0;
>  int line  = 0;
> 
> @@ -104,6 +104,7 @@ static int davs2_dump_frames(AVCodecContext
> *avctx, davs2_picture_t *pic, int *g
> 
>  for (plane = 0; plane < 3; ++plane) {
>  int size_line = pic->widths[plane] * bytes_per_sample;
> +void *dst, *src;
>  frame->buf[plane]  = av_buffer_alloc(size_line * pic->lines[plane]);
> 
>  if (!frame->buf[plane]){
> @@ -114,10 +115,14 @@ static int davs2_dump_frames(AVCodecContext
> *avctx, davs2_picture_t *pic, int *g
>  frame->data[plane] = frame->buf[plane]->data;
>  frame->linesize[plane] = size_line;
> 

Did you observe performance difference with only below lines of change?
If it is just for code cleanup, it's better to split this into separate patch.

Thanks!
Ruiling
> -for (line = 0; line < pic->lines[plane]; ++line)
> -memcpy(frame->data[plane] + line * size_line,
> -   pic->planes[plane] + line * pic->strides[plane],
> -   pic->widths[plane] * bytes_per_sample);
> +dst = frame->data[plane];
> +src = pic->planes[plane];
> +
> +for (line = 0; line < pic->lines[plane]; ++line) {
> +memcpy(dst, src, size_line);
> +dst += size_line;
> +src += pic->strides[plane];
> +}
>  }
> 
>  frame->width = cad->headerset.width;
> --
> 2.7.4
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the AMF section

2019-07-04 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: Friday, July 5, 2019 2:27 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the AMF
> section
> 
> 
> On Thu, 4 Jul 2019, Hendrik Leppkes wrote:
> 
> > On Thu, Jul 4, 2019 at 12:42 AM Lynne  wrote:
> >>
> >> NAK for reasons said on IRC
> >
> > For everyones benefit, why don't you actually formulate your reasons
> > here instead of asking people to piece them together from some chat
> > history, that way people can actually understand or respond to them.
> > I, for one, could not find an actual reason you listed that actually 
> > applies.
> 
> Also irclogs mailing list archives stopped working not long ago, maybe
> someone can take a look?
Burek said he will take a look at the issue.

> 
> Thanks,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add x86 SIMD for filter_3x3()

2019-07-14 Thread Song, Ruiling
> -Original Message-
> From: Song, Ruiling
> Sent: Tuesday, July 9, 2019 9:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling 
> Subject: [PATCH] avfilter/vf_convolution: add x86 SIMD for filter_3x3()
> 
> Tested using a simple command (apply edge enhance):
> ./ffmpeg_g -i ~/Downloads/bbb_sunflower_1080p_30fps_normal.mp4 \
>  -vf convolution="0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 
> 0 0 -1 1 0 0
> 0 0:5:1:1:1:0:128:128:128" \
>  -an -vframes 1000 -f null /dev/null
> 
> The fps increase from 151 to 270 on my local machine.
> 
> Signed-off-by: Ruiling Song 
Ping?

> ---
>  libavfilter/convolution.h |  64 +++
>  libavfilter/vf_convolution.c  |  41 +--
>  libavfilter/x86/Makefile  |   2 +
>  libavfilter/x86/vf_convolution.asm| 158 ++
>  libavfilter/x86/vf_convolution_init.c |  46 
>  5 files changed, 273 insertions(+), 38 deletions(-)
>  create mode 100644 libavfilter/convolution.h
>  create mode 100644 libavfilter/x86/vf_convolution.asm
>  create mode 100644 libavfilter/x86/vf_convolution_init.c
> 
> diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
> new file mode 100644
> index 00..fc6aad58fd
> --- /dev/null
> +++ b/libavfilter/convolution.h
> @@ -0,0 +1,64 @@
> +/*
> + * Copyright (c) 2012-2013 Oka Motofumi (chikuzen.mo at gmail dot com)
> + * Copyright (c) 2015 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +#ifndef AVFILTER_CONVOLUTION_H
> +#define AVFILTER_CONVOLUTION_H
> +#include "avfilter.h"
> +
> +enum MatrixMode {
> +MATRIX_SQUARE,
> +MATRIX_ROW,
> +MATRIX_COLUMN,
> +MATRIX_NBMODES,
> +};
> +
> +typedef struct ConvolutionContext {
> +const AVClass *class;
> +
> +char *matrix_str[4];
> +float rdiv[4];
> +float bias[4];
> +int mode[4];
> +float scale;
> +float delta;
> +int planes;
> +
> +int size[4];
> +int depth;
> +int max;
> +int bpc;
> +int nb_planes;
> +int nb_threads;
> +int planewidth[4];
> +int planeheight[4];
> +int matrix[4][49];
> +int matrix_length[4];
> +int copy[4];
> +
> +void (*setup[4])(int radius, const uint8_t *c[], const uint8_t *src, int 
> stride,
> + int x, int width, int y, int height, int bpc);
> +void (*filter[4])(uint8_t *dst, int width,
> +  float rdiv, float bias, const int *const matrix,
> +  const uint8_t *c[], int peak, int radius,
> +  int dstride, int stride);
> +} ConvolutionContext;
> +
> +void ff_convolution_init_x86(ConvolutionContext *s);
> +#endif
> diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
> index 1305569c88..e3bf1df79f 100644
> --- a/libavfilter/vf_convolution.c
> +++ b/libavfilter/vf_convolution.c
> @@ -25,48 +25,11 @@
>  #include "libavutil/opt.h"
>  #include "libavutil/pixdesc.h"
>  #include "avfilter.h"
> +#include "convolution.h"
>  #include "formats.h"
>  #include "internal.h"
>  #include "video.h"
> 
> -enum MatrixMode {
> -MATRIX_SQUARE,
> -MATRIX_ROW,
> -MATRIX_COLUMN,
> -MATRIX_NBMODES,
> -};
> -
> -typedef struct ConvolutionContext {
> -const AVClass *class;
> -
> -char *matrix_str[4];
> -float rdiv[4];
> -float bias[4];
> -int mode[4];
> -float scale;
> -float delta;
> -int planes;
> -
> -int size[4];
> -int depth;
> -int max;
> -int bpc;
> -int nb_planes;
> -int nb_threads;
> -int planewidth[4];
> -int planeheight[4];
> -int matrix[4][49];
> -int matrix_length[4];
> -int copy[4];
> -
> -void (*setup[4])(int rad

Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

2019-04-21 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Saturday, April 20, 2019 11:08 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl
> filter
> 
> On 17/04/2019 03:43, Song, Ruiling wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of
> >> Mark Thompson
> >> Sent: Wednesday, April 17, 2019 5:28 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl
> >> filter
> >>
> >> On 12/04/2019 16:09, Ruiling Song wrote:
> >>> Signed-off-by: Ruiling Song 
> >>
> >> I can't work out where the problem is, but there is something really 
> >> weirdly
> >> nondeterministic going on here.
> >>
> >> E.g.
> >>
> >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-120-
> mbps-
> >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> >> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> >> frames:v 10 -f framemd5 -
> >> ...
> >> 0,  0,  0,1, 12441600, 
> >> 8b8805818076b23ae6f80ec2b5a349d4
> >> 0,  1,  1,1, 12441600, 
> >> 7a7fdaa083dc337cfb6af31b643f30a3
> >> 0,  2,  2,1, 12441600, 
> >> b10ef2a1e5125cc67e262e086f8040b5
> >> 0,  3,  3,1, 12441600, 
> >> c06b53ad90e0357e537df41b63d5b1dc
> >> 0,  4,  4,1, 12441600, 
> >> 5aa2da07703859a3dee080847dd17d46
> >> 0,  5,  5,1, 12441600, 
> >> 733364c6be6af825057e905a6092937d
> >> 0,  6,  6,1, 12441600, 
> >> 47edae2dec956a582b04babb745d26b0
> >> 0,  7,  7,1, 12441600, 
> >> 4e45fe8268df4298d06a17ab8e46c3e9
> >> 0,  8,  8,1, 12441600, 
> >> 960d722a3f8787c9191299a114c04174
> >> 0,  9,  9,1, 12441600, 
> >> e759c07ee4834a9cf94bfcb4128e7612
> >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-120-
> mbps-
> >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> >> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> >> frames:v 10 -f framemd5 -
> >> 0,  0,  0,1, 12441600, 
> >> 8b8805818076b23ae6f80ec2b5a349d4
> >> [Parsed_nlmeans_opencl_2 @ 0x5557ae580d00] integral image overflow
> >> 2157538
> >> 0,  1,  1,1, 12441600, 
> >> bce72e10a9f1118940c5a8392ad78ec3
> >> 0,  2,  2,1, 12441600, 
> >> b10ef2a1e5125cc67e262e086f8040b5
> >> 0,  3,  3,1, 12441600, 
> >> c06b53ad90e0357e537df41b63d5b1dc
> >> 0,  4,  4,1, 12441600, 
> >> 5aa2da07703859a3dee080847dd17d46
> >> 0,  5,  5,1, 12441600, 
> >> 733364c6be6af825057e905a6092937d
> >> 0,  6,  6,1, 12441600, 
> >> 47edae2dec956a582b04babb745d26b0
> >> 0,  7,  7,1, 12441600, 
> >> 4e45fe8268df4298d06a17ab8e46c3e9
> >> 0,  8,  8,1, 12441600, 
> >> 960d722a3f8787c9191299a114c04174
> >> 0,  9,  9,1, 12441600, 
> >> e759c07ee4834a9cf94bfcb4128e7612
> >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-120-
> mbps-
> >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> >> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> >> frames:v 10 -f framemd5 -
> >> 0,  0,  0,1, 12441600, 
> >> 8b8805818076b23ae6f80ec2b5a349d4
> >> 0,  1,  1,1, 12441600, 
> >> 7a7fdaa083dc337cfb6af31b643f30a3
> >> [Parsed_nlmeans_opencl_2 @ 0x557c51fbfe80] integral image overflow
> >> 2098545
> >> 0,  2,  2,1, 12441600, 
> >> 68b390535adc5cfa0f8a7942c42a47ca
> >> 0,  3,  3,1, 12441600, 
> >> c06b53ad90e0357e537df41b63d5b1dc
> >> 0,  4,  4,1, 12441600, 
> >> 5aa2da07703859a3dee080847dd17d46
> >> 0,  5,  5,1, 12441600, 
> >> 733364c6be6af825057e905a6092937d
> >

Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter

2019-04-23 Thread Song, Ruiling


> -Original Message-
> From: Song, Ruiling
> Sent: Sunday, April 21, 2019 8:18 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl filter
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of
> > Mark Thompson
> > Sent: Saturday, April 20, 2019 11:08 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> nlmeans_opencl
> > filter
> >
> > On 17/04/2019 03:43, Song, Ruiling wrote:
> > >> -Original Message-
> > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of
> > >> Mark Thompson
> > >> Sent: Wednesday, April 17, 2019 5:28 AM
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add
> > nlmeans_opencl
> > >> filter
> > >>
> > >> On 12/04/2019 16:09, Ruiling Song wrote:
> > >>> Signed-off-by: Ruiling Song 
> > >>
> > >> I can't work out where the problem is, but there is something really
> weirdly
> > >> nondeterministic going on here.
> > >>
> > >> E.g.
> > >>
> > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-120-
> > mbps-
> > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > >>
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > >> frames:v 10 -f framemd5 -
> > >> ...
> > >> 0,  0,  0,1, 12441600, 
> > >> 8b8805818076b23ae6f80ec2b5a349d4
> > >> 0,  1,  1,1, 12441600, 
> > >> 7a7fdaa083dc337cfb6af31b643f30a3
> > >> 0,  2,  2,1, 12441600, 
> > >> b10ef2a1e5125cc67e262e086f8040b5
> > >> 0,  3,  3,1, 12441600, 
> > >> c06b53ad90e0357e537df41b63d5b1dc
> > >> 0,  4,  4,1, 12441600, 
> > >> 5aa2da07703859a3dee080847dd17d46
> > >> 0,  5,  5,1, 12441600, 
> > >> 733364c6be6af825057e905a6092937d
> > >> 0,  6,  6,1, 12441600, 
> > >> 47edae2dec956a582b04babb745d26b0
> > >> 0,  7,  7,1, 12441600, 
> > >> 4e45fe8268df4298d06a17ab8e46c3e9
> > >> 0,  8,  8,1, 12441600, 
> > >> 960d722a3f8787c9191299a114c04174
> > >> 0,  9,  9,1, 12441600, 
> > >> e759c07ee4834a9cf94bfcb4128e7612
> > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-120-
> > mbps-
> > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > >>
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > >> frames:v 10 -f framemd5 -
> > >> 0,  0,  0,1, 12441600, 
> > >> 8b8805818076b23ae6f80ec2b5a349d4
> > >> [Parsed_nlmeans_opencl_2 @ 0x5557ae580d00] integral image
> overflow
> > >> 2157538
> > >> 0,  1,  1,1, 12441600, 
> > >> bce72e10a9f1118940c5a8392ad78ec3
> > >> 0,  2,  2,1, 12441600, 
> > >> b10ef2a1e5125cc67e262e086f8040b5
> > >> 0,  3,  3,1, 12441600, 
> > >> c06b53ad90e0357e537df41b63d5b1dc
> > >> 0,  4,  4,1, 12441600, 
> > >> 5aa2da07703859a3dee080847dd17d46
> > >> 0,  5,  5,1, 12441600, 
> > >> 733364c6be6af825057e905a6092937d
> > >> 0,  6,  6,1, 12441600, 
> > >> 47edae2dec956a582b04babb745d26b0
> > >> 0,  7,  7,1, 12441600, 
> > >> 4e45fe8268df4298d06a17ab8e46c3e9
> > >> 0,  8,  8,1, 12441600, 
> > >> 960d722a3f8787c9191299a114c04174
> > >> 0,  9,  9,1, 12441600, 
> > >> e759c07ee4834a9cf94bfcb4128e7612
> > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish-120-
> > mbps-
> > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf
> > >>
> format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p -
> > >> frames:v 10 -f framemd5 -
>

Re: [FFmpeg-devel] [PATCH V2 1/2] lavfi/opencl: add more opencl helper macro

2019-04-25 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, April 17, 2019 5:25 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2 1/2] lavfi/opencl: add more opencl
> helper macro
> 
> On 12/04/2019 16:09, Ruiling Song wrote:
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavfilter/opencl.h | 38 ++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
> > index 0b06232ade..0fa5b49d3f 100644
> > --- a/libavfilter/opencl.h
> > +++ b/libavfilter/opencl.h
> > @@ -73,6 +73,44 @@ typedef struct OpenCLFilterContext {
> >  goto fail; \
> >  }  \
> >  } while(0)
> > +/**
> > +  * release an OpenCL Kernel
> > +  */
> > +#define CL_RELEASE_KERNEL(k)  \
> > +do {  \
> > +if (k) {  \
> > +cle = clReleaseKernel(k); \
> > +if (cle != CL_SUCCESS)\
> > +av_log(avctx, AV_LOG_ERROR, "Failed to release "  \
> > +   "OpenCL kernel: %d.\n", cle);  \
> > +} \
> > +} while(0)
> > +
> > +/**
> > +  * release an OpenCL Memory Object
> > +  */
> > +#define CL_RELEASE_MEMORY(m)  \
> > +do {  \
> > +if (m) {  \
> > +cle = clReleaseMemObject(m);  \
> > +if (cle != CL_SUCCESS)\
> > +av_log(avctx, AV_LOG_ERROR, "Failed to release "  \
> > +   "OpenCL memory: %d.\n", cle);  \
> > +} \
> > +} while(0)
> > +
> > +/**
> > +  * release an OpenCL Command Queue
> > +  */
> > +#define CL_RELEASE_QUEUE(q)   \
> > +do {  \
> > +if (q) {  \
> > +cle = clReleaseCommandQueue(q);   \
> > +if (cle != CL_SUCCESS)\
> > +av_log(avctx, AV_LOG_ERROR, "Failed to release "  \
> > +   "cl command queue: %d.\n", cle);   \
> > +} \
> > +} while(0)
> >
> >  /**
> >   * Return that all inputs and outputs support only AV_PIX_FMT_OPENCL.
> >
> 
> LGTM.
Pushed this patch so we can use it in other opencl filters. Thanks!
> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/7] Import some x264asm patches from x264

2019-08-12 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Darnley
> Sent: Monday, August 5, 2019 9:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 0/7] Import some x264asm patches from
> x264
> 
> Here are a few easy-to-import patches from x264.  These are all after x264
> commit 4a158b00 "x86inc: Correctly set mmreg variables" which FFmpeg
> already
> has (commit eb5f063e7c).
> 
> It does not include the following commits:
> * 82721eae "x86inc: Add x86-32 PIC support macros"
> * 101bd27d "x86inc: Support N_PEXT bit on Mach-O"
> 
> They would not apply cleanly because of existing differences between x264
> and
> FFmpeg.  The PIC one has a change to configure which would need remaking.
> 
> Henrik Gramner (7):
>   x86inc: Fix VEX -> EVEX instruction conversion
>   x86inc: Optimize VEX instruction encoding
>   x86inc: Improve SAVE/LOAD_MM_PERMUTATION macros
>   x86inc: Turn 'movsxd' into 'movifnidn' on x86-32
>   x86inc: Make 'non-adjacent' default in the TAIL_CALL macro
>   x86inc: Improve warnings for use of unsupported instructions
>   x86inc: Add support for GFNI instructions
> 
>  libavutil/x86/x86inc.asm | 219 ---
>  1 file changed, 161 insertions(+), 58 deletions(-)
> 
I think it is a good idea to apply such changes. No sure if anybody else has 
different opinion.

Ruiling
> --
> 2.22.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures

2019-08-12 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Andreas Rheinhardt
> Sent: Monday, August 12, 2019 9:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures
> 
> 98e419cb added SIMD for the convolution filter for x64 systems. As
> usual, it used a check of the form
> if (ARCH_X86_64)
> ff_convolution_init_x86(s);
> and thereby relied on the compiler eliminating this pseudo-runtime check
> at compiletime for non x64 systems (for which ff_convolution_init_x86
> isn't defined) to compile. But vf_convolution.c contains more than one
> filter and if the convolution filter is disabled, but one of the other
> filters (prewitt, sobel, roberts) is enabled, the build will fail on x64,
> because ff_convolution_init_x86 isn't defined in this case.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
Will apply.

> Found via ubitux2's random FATE box:
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-random
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures

2019-08-11 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Andreas Rheinhardt
> Sent: Monday, August 12, 2019 9:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: Fix build failures
> 
> 98e419cb added SIMD for the convolution filter for x64 systems. As
> usual, it used a check of the form
> if (ARCH_X86_64)
> ff_convolution_init_x86(s);
> and thereby relied on the compiler eliminating this pseudo-runtime check
> at compiletime for non x64 systems (for which ff_convolution_init_x86
> isn't defined) to compile. But vf_convolution.c contains more than one
> filter and if the convolution filter is disabled, but one of the other
> filters (prewitt, sobel, roberts) is enabled, the build will fail on x64,
> because ff_convolution_init_x86 isn't defined in this case.

Sorry I missed that. Thanks for the fix. The patch LGTM.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Found via ubitux2's random FATE box:
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-random
> 
>  libavfilter/vf_convolution.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
> index e3bf1df79f..f29df38a20 100644
> --- a/libavfilter/vf_convolution.c
> +++ b/libavfilter/vf_convolution.c
> @@ -588,8 +588,9 @@ static int config_input(AVFilterLink *inlink)
>  s->filter[p] = filter16_7x7;
>  }
>  }
> -if (ARCH_X86_64)
> -ff_convolution_init_x86(s);
> +#if CONFIG_CONVOLUTION_FILTER && ARCH_X86_64
> +ff_convolution_init_x86(s);
> +#endif
>  } else if (!strcmp(ctx->filter->name, "prewitt")) {
>  if (s->depth > 8)
>  for (p = 0; p < s->nb_planes; p++)
> --
> 2.21.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add x86 SIMD for filter_3x3()

2019-07-31 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, July 17, 2019 8:42 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add x86 SIMD
> for filter_3x3()
> 
> On 7/15/19, Song, Ruiling  wrote:
> >> -----Original Message-
> >> From: Song, Ruiling
> >> Sent: Tuesday, July 9, 2019 9:15 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Song, Ruiling 
> >> Subject: [PATCH] avfilter/vf_convolution: add x86 SIMD for filter_3x3()
> >>
> >> Tested using a simple command (apply edge enhance):
> >> ./ffmpeg_g -i ~/Downloads/bbb_sunflower_1080p_30fps_normal.mp4 \
> >>  -vf convolution="0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0
> >> 0:0 0 0 -1 1 0 0
> >> 0 0:5:1:1:1:0:128:128:128" \
> >>  -an -vframes 1000 -f null /dev/null
> >>
> >> The fps increase from 151 to 270 on my local machine.
> >>
> >> Signed-off-by: Ruiling Song 
> > Ping?
> 
> Should be fine IFF output is exact with C version (under different
> parameters).
Thanks Paul, after fixing a bug in scalar code path, the v2 produces exact 
result as C version.
Have tested against many different parameters. Will apply in a few days.

Thanks!
Ruiling

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2] avfilter/vf_convolution: add x86 SIMD for filter_3x3()

2019-08-07 Thread Song, Ruiling
> -Original Message-
> From: Song, Ruiling
> Sent: Wednesday, July 31, 2019 3:54 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling 
> Subject: [PATCH V2] avfilter/vf_convolution: add x86 SIMD for filter_3x3()
> 
> Tested using a simple command (apply edge enhance):
> ./ffmpeg_g -i ~/Downloads/bbb_sunflower_1080p_30fps_normal.mp4 \
>  -vf convolution="0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 
> 0 0 -1 1 0 0
> 0 0:5:1:1:1:0:128:128:128" \
>  -an -vframes 1000 -f null /dev/null
> 
> The fps increase from 151 to 270 on my local machine.
> 
> Signed-off-by: Ruiling Song 
> ---
> v2:
>   fix a bug in scalar code path.
>   Use macro PROCESS_V/S for the first tap to simplify code.
Applied this version.

> 
>  libavfilter/convolution.h |  64 +++
>  libavfilter/vf_convolution.c  |  41 +--
>  libavfilter/x86/Makefile  |   2 +
>  libavfilter/x86/vf_convolution.asm| 156 ++
>  libavfilter/x86/vf_convolution_init.c |  46 
>  5 files changed, 271 insertions(+), 38 deletions(-)
>  create mode 100644 libavfilter/convolution.h
>  create mode 100644 libavfilter/x86/vf_convolution.asm
>  create mode 100644 libavfilter/x86/vf_convolution_init.c
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for FFSIGN(0)

2019-07-17 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Ulf Zibis
> Sent: Wednesday, July 17, 2019 2:34 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for
> FFSIGN(0)
> 
> Again with the patch attached ...
> 
> Am 17.07.19 um 08:30 schrieb Ulf Zibis:
> > Hi,
> >
> > I have a patch for bug #8027  (see
> > attachment).
Why do you think FFSIGN(0.0) should return +1? What issue do you meet?
I think the value of FFSIGN(0) depends on how we define the behavior of 
FFSIGN().

Thanks!
Ruiling
> >
> > But there is still a problem with -0.0, but FFABS(-0.0) works fine.
> >
> > Testcode:
> >    av_log(NULL, AV_LOG_ERROR, "FFSIGN(0): %d\n", FFSIGN(0));
> >     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0): %d\n", FFSIGN(-0));
> >     av_log(NULL, AV_LOG_ERROR, "FFSIGN(0.0D): %d\n", FFSIGN(0.0D));
> >     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0D): %d\n", FFSIGN(-0.0D));
> >     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0F): %d\n", FFSIGN(-0.0F));
> >     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0): %d\n", FFSIGN(-0.0));
> >
> >     av_log(NULL, AV_LOG_ERROR, "FFABS(0): %d\n", FFABS(0));
> >     av_log(NULL, AV_LOG_ERROR, "FFABS(-0): %d\n", FFABS(-0));
> >     av_log(NULL, AV_LOG_ERROR, "FFABS(0.0D): %f\n", FFABS(0.0D));
> >     av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0D): %f\n", FFABS(-0.0D));
> >     av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0F): %f\n", FFABS(-0.0F));
> >     av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0): %f\n", FFABS(-0.0));
> >
> > Results:
> > FFSIGN(0): 1
> > FFSIGN(-0): 1
> > FFSIGN(0.0D): 1
> > FFSIGN(-0.0D): 1
> > FFSIGN(-0.0F): 1
> > FFSIGN(-0.0): 1
> > FFABS(0): 0
> > FFABS(-0): 0
> > FFABS(0.0D): 0.00
> > FFABS(-0.0D): -0.00
> > FFABS(-0.0F): -0.00
> > FFABS(-0.0): -0.00
> >
> > -Ulf
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1 1/2] lavu/pixfmt: add new pixel format a2r10g10b10/a2b10g10r10

2019-09-27 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Carl Eugen Hoyos
> Sent: Friday, September 27, 2019 7:47 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v1 1/2] lavu/pixfmt: add new pixel
> format a2r10g10b10/a2b10g10r10
> 
> Am Fr., 27. Sept. 2019 um 11:02 Uhr schrieb Sun, Xinpeng
> :
> 
> > > > Add two 10 bit RGBA pixel format for hardware color space conversion
> > > > support in VAAPI and QSV:
> > > >
> > > > 2:10:10:10 10 bit: A2R10G10B10
> > > > 2:10:10:10 10 bit: A2B10G10R10
> > >
> > > Without more explanation, this patch is not ok.
> 
> > The main reasons for adding these two format are as follows:
> > 1. For most HDR monitors, A2R10G10B10 is used for display format for
> > rendering. So this format is important to do 10bit RGB rendering support
> > in ffmpeg.
> 
> For which operating systems (and video drivers) is this true?
Here:
https://docs.microsoft.com/en-us/windows/win32/direct3d9/d3dformat
and here:
https://docs.microsoft.com/en-us/windows/win32/directshow/uncompressed-rgb-video-subtypes

It is defined in Windows APIs. so I guess these are widely used 10bit RGB 
format on Windows?

> And which video players will profit from this filter?
> 
> > 2. HW VPP can do both p010->a2r10g10b10 and a2r10g10b10->p010
> > with this patch, which can provide support for hw encode pipeline
> > using a2r10g10b10 as input.
> 
> But if the pipeline (that you control, no?) would support GBRP10, not
> only one (very) specific use case would be supported but all thinkable
> use cases, or do I misunderstand?
AFAIK, Intel GPU does not support planar RGB10 currently. May be we can add 
some format conversion between GBRP10 and the new added formats in swscale? (I 
am not if this could help the thinkable use cases you mean.)
And could you share your thought why supporting planar RGB10 is important? 
Thanks!

Ruiling
> 
> Afaict, the fact that FFmpeg cannot deal at all with HDR is the most
> pressing issue we have atm. I believe that only solving this problem
> for one specific use case is not the ideal solution.
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 1/3] checkasm/vf_eq: add test for vf_eq

2019-09-23 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Ting Fu
> Sent: Wednesday, September 18, 2019 3:06 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V2 1/3] checkasm/vf_eq: add test for vf_eq
> 
> Signed-off-by: Ting Fu 

The patchset LGTM. Have also verified on linux64, win64 and linux32.
Will apply the patches if no objection.
There are some indention errors, have fixed them locally. Please take care next 
time.

Ruiling

> ---
>  libavfilter/vf_eq.c   | 13 ---
>  libavfilter/vf_eq.h   |  1 +
>  tests/checkasm/Makefile   |  1 +
>  tests/checkasm/checkasm.c |  3 ++
>  tests/checkasm/checkasm.h |  1 +
>  tests/checkasm/vf_eq.c| 79
> +++
>  tests/fate/checkasm.mak   |  1 +
>  7 files changed, 94 insertions(+), 5 deletions(-)
>  create mode 100644 tests/checkasm/vf_eq.c
> 
> diff --git a/libavfilter/vf_eq.c b/libavfilter/vf_eq.c
> index 2c4c7e4d54..0f9d129255 100644
> --- a/libavfilter/vf_eq.c
> +++ b/libavfilter/vf_eq.c
> @@ -174,12 +174,18 @@ static int set_expr(AVExpr **pexpr, const char
> *expr, const char *option, void *
>  return 0;
>  }
> 
> +void ff_eq_init(EQContext *eq)
> +{
> +eq->process = process_c;
> +if (ARCH_X86)
> +ff_eq_init_x86(eq);
> +}
> +
>  static int initialize(AVFilterContext *ctx)
>  {
>  EQContext *eq = ctx->priv;
>  int ret;
> -
> -eq->process = process_c;
> +ff_eq_init(eq);
> 
>  if ((ret = set_expr(>contrast_pexpr, eq->contrast_expr,
> "contrast", ctx)) < 0 ||
>  (ret = set_expr(>brightness_pexpr,   eq->brightness_expr,
> "brightness",   ctx)) < 0 ||
> @@ -191,9 +197,6 @@ static int initialize(AVFilterContext *ctx)
>  (ret = set_expr(>gamma_weight_pexpr, eq->gamma_weight_expr,
> "gamma_weight", ctx)) < 0 )
>  return ret;
> 
> -if (ARCH_X86)
> -ff_eq_init_x86(eq);
> -
>  if (eq->eval_mode == EVAL_MODE_INIT) {
>  set_gamma(eq);
>  set_contrast(eq);
> diff --git a/libavfilter/vf_eq.h b/libavfilter/vf_eq.h
> index fa49d46e5c..cd0cd75f08 100644
> --- a/libavfilter/vf_eq.h
> +++ b/libavfilter/vf_eq.h
> @@ -100,6 +100,7 @@ typedef struct EQContext {
>  enum EvalMode { EVAL_MODE_INIT, EVAL_MODE_FRAME,
> EVAL_MODE_NB } eval_mode;
>  } EQContext;
> 
> +void ff_eq_init(EQContext *eq);
>  void ff_eq_init_x86(EQContext *eq);
> 
>  #endif /* AVFILTER_EQ_H */
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 0112ff603e..de850c016e 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -36,6 +36,7 @@ CHECKASMOBJS-$(CONFIG_AVCODEC)  +=
> $(AVCODECOBJS-yes)
>  AVFILTEROBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
>  AVFILTEROBJS-$(CONFIG_BLEND_FILTER) += vf_blend.o
>  AVFILTEROBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o
> +AVFILTEROBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
>  AVFILTEROBJS-$(CONFIG_GBLUR_FILTER)  += vf_gblur.o
>  AVFILTEROBJS-$(CONFIG_HFLIP_FILTER)  += vf_hflip.o
>  AVFILTEROBJS-$(CONFIG_THRESHOLD_FILTER)  += vf_threshold.o
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index d9a5c7f401..bcbe775510 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -165,6 +165,9 @@ static const struct {
>  #if CONFIG_COLORSPACE_FILTER
>  { "vf_colorspace", checkasm_check_colorspace },
>  #endif
> +#if CONFIG_EQ_FILTER
> +{ "vf_eq", checkasm_check_vf_eq },
> +#endif
>  #if CONFIG_GBLUR_FILTER
>  { "vf_gblur", checkasm_check_vf_gblur },
>  #endif
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index fdf9eeb75d..0a7f9f25c4 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -72,6 +72,7 @@ void checkasm_check_sw_rgb(void);
>  void checkasm_check_utvideodsp(void);
>  void checkasm_check_v210dec(void);
>  void checkasm_check_v210enc(void);
> +void checkasm_check_vf_eq(void);
>  void checkasm_check_vf_gblur(void);
>  void checkasm_check_vf_hflip(void);
>  void checkasm_check_vf_threshold(void);
> diff --git a/tests/checkasm/vf_eq.c b/tests/checkasm/vf_eq.c
> new file mode 100644
> index 00..684718f2cd
> --- /dev/null
> +++ b/tests/checkasm/vf_eq.c
> @@ -0,0 +1,79 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin 

Re: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for H2S

2019-12-02 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Fu,
> Linjie
> Sent: Tuesday, December 3, 2019 11:23 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Sun, Xinpeng ; Zhou, Zachary
> 
> Subject: Re: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for
> H2S
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Xinpeng Sun
> > Sent: Monday, December 2, 2019 15:17
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Sun, Xinpeng ; Zhou, Zachary
> > 
> > Subject: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for
> > H2S
> >
> > It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> > conversion
> > with tone-mapping. It only supports HDR10 as input temporarily.
> >
> > An example command to use this filter with vaapi codecs:
> > FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -
> > hwaccel_output_format vaapi \
> > -i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2
> > OUTPUT
> >
> > Signed-off-by: Xinpeng Sun 
> > Signed-off-by: Zachary Zhou 
> > ---
> >  configure  |   2 +
> >  doc/filters.texi   |  81 +++
> >  libavfilter/Makefile   |   1 +
> >  libavfilter/allfilters.c   |   1 +
> >  libavfilter/vf_tonemap_vaapi.c | 420
> > +
> >  5 files changed, 505 insertions(+)
> >  create mode 100644 libavfilter/vf_tonemap_vaapi.c
> >
> > diff --git a/configure b/configure
> > index ca7137f341..5272fb2a57 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3576,6 +3576,7 @@ tinterlace_filter_deps="gpl"
> >  tinterlace_merge_test_deps="tinterlace_filter"
> >  tinterlace_pad_test_deps="tinterlace_filter"
> >  tonemap_filter_deps="const_nan"
> > +tonemap_vaapi_filter_deps="vaapi
> > VAProcPipelineParameterBuffer_output_hdr_metadata"
> >  tonemap_opencl_filter_deps="opencl const_nan"
> >  transpose_opencl_filter_deps="opencl"
> >  transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
> > @@ -6576,6 +6577,7 @@ if enabled vaapi; then
> >
> >  check_type "va/va.h va/va_dec_hevc.h"
> > "VAPictureParameterBufferHEVC"
> >  check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineParameterBuffer"
> > output_hdr_metadata
> >  check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> rotation_flags
> >  check_type "va/va.h va/va_enc_hevc.h"
> > "VAEncPictureParameterBufferHEVC"
> >  check_type "va/va.h va/va_enc_jpeg.h"
> > "VAEncPictureParameterBufferJPEG"
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 5fdec6f015..7223ab89a3 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -20972,6 +20972,87 @@ Apply a strong blur of both luma and chroma
> > parameters:
> >
> >  @c man end OPENCL VIDEO FILTERS
> >
> > +@chapter VAAPI Video Filters
> > +@c man begin VAAPI VIDEO FILTERS
> > +
> > +VAAPI Video filters are usually used with VAAPI decoder and VAAPI
> > encoder. Below is a description of VAAPI video filters.
> > +
> > +To enable compilation of these filters you need to configure FFmpeg with
> > +@code{--enable-vaapi}.
> > +
> > +Running VAAPI filters requires you to initialize a hardware device and to
> > pass that device to all filters in any filter graph.
> > +@table @option
> > +
> > +@item -hwaccel vaapi
> > +Specify the hardware accelerator as @var{vaapi}.
> > +
> > +@item -vaapi_device @var{driver_path}
> > +Specify the vaapi driver path with @var{driver_path}.
> > +
> > +@item -hwaccel_output_format @var{vaapi}
> > +Specify the output format of hardware accelerator as @var{vaapi}. All
> > VAAPI hardware surfaces in ffmpeg are represented by the @var{vaapi}
> > pixfmt.
> > +
> > +@end table
> > +
> > +@itemize
> > +@item
> > +Example of running tonemap_vaapi filter with default parameters on it.
> > +@example
> > +-hwaccel vaapi -vaapi_device /dev/dri/renderD128 -
> > hwaccel_output_format vaapi -i INPUT -vf "tonemap_vaapi, hwdownload"
> > OUTPUT
> > +@end example
> > +@end itemize
> > +
> > +Since VAAPI filters are not able to access frame data in arbitrary memory,
> so
> > if you use a decoder other than VAAPI decoder before VAAPI filters, all
> > frame data needs to be uploaded(@ref{hwupload}) to hardware surfaces
> > connected to the appropriate device before being used. Also if you add a
> > encoder other than VAAPI encoder after VAAPI filters,
> 
> How about VAAPI decoder/filter + QSV encoder?
I think hwmap may help on this. anyway we can further enhance the document 
later if you have good idea.

Ruiling
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for H2S

2019-12-02 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Vittorio Giovara
> Sent: Tuesday, December 3, 2019 2:28 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Sun, Xinpeng ; Zhou, Zachary
> 
> Subject: Re: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for
> H2S
> 
> On Mon, Dec 2, 2019 at 2:19 AM Xinpeng Sun 
> wrote:
> 
> > It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> > conversion
> > with tone-mapping. It only supports HDR10 as input temporarily.
> >
> > An example command to use this filter with vaapi codecs:
> > FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi \
> > -i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2
> OUTPUT
> >
> > Signed-off-by: Xinpeng Sun 
> > Signed-off-by: Zachary Zhou 
> > ---
> >  configure  |   2 +
> >  doc/filters.texi   |  81 +++
> >  libavfilter/Makefile   |   1 +
> >  libavfilter/allfilters.c   |   1 +
> >  libavfilter/vf_tonemap_vaapi.c | 420
> +
> >  5 files changed, 505 insertions(+)
> >  create mode 100644 libavfilter/vf_tonemap_vaapi.c
> >
[...]
> > +static int tonemap_vaapi_save_metadata(AVFilterContext *avctx,
> AVFrame
> > *input_frame)
> > +{
> > +HDRVAAPIContext *ctx = avctx->priv;
> > +AVMasteringDisplayMetadata *hdr_meta;
> > +AVContentLightMetadata *light_meta;
> > +
> > +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > +av_log(avctx, AV_LOG_WARNING, "Only support HDR10 as input for
> > vaapi tone-mapping\n");
> > +input_frame->color_trc = AVCOL_TRC_SMPTE2084;
I think we don't need to modify the input->color_trc here. I am not sure if 
this has any side-effect, but may be misleading if you want to check that value 
when debugging.
Simply remove this single line would be ok.

[...]
> > +err = av_frame_copy_props(output_frame, input_frame);
> > +if (err < 0)
> > +return err;
> > +
> > +if (ctx->color_primaries != AVCOL_PRI_UNSPECIFIED)
> > +output_frame->color_primaries = ctx->color_primaries;
> > +
> > +if (ctx->color_transfer != AVCOL_TRC_UNSPECIFIED)
> > +output_frame->color_trc = ctx->color_transfer;
> > +else
> > +output_frame->color_trc = AVCOL_TRC_BT709
> >
> 
> why does only this setting get special treatment?
Basically for other properties we can copy from the source, but for color_trc, 
we cannot.
And I guess bt709 is a widely used sdr format. So even if user does not give a 
target transfer characteristic, we use this default one.

[...]
> 
> Overall this lgtm, I'd push it but I don't have a platform to test it on.
Really appreciate that. I borrow an icelake from other team member and have a 
test on this patch, the tone-mapping result video basically looks good.

Ruiling
> --
> Vittorio
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for H2S

2019-12-10 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Vittorio Giovara
> Sent: Tuesday, December 3, 2019 2:28 AM
> To: FFmpeg development discussions and patches 
> Cc: Sun, Xinpeng ; Zhou, Zachary
> 
> Subject: Re: [FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for
> H2S
> 
> On Mon, Dec 2, 2019 at 2:19 AM Xinpeng Sun  wrote:
> 
> > It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> > conversion
> > with tone-mapping. It only supports HDR10 as input temporarily.
> >
> > An example command to use this filter with vaapi codecs:
> > FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi \
> > -i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2 OUTPUT
> >
> > Signed-off-by: Xinpeng Sun 
> > Signed-off-by: Zachary Zhou 
> > ---
> >  configure  |   2 +
> >  doc/filters.texi   |  81 +++
> >  libavfilter/Makefile   |   1 +
> >  libavfilter/allfilters.c   |   1 +
> >  libavfilter/vf_tonemap_vaapi.c | 420
> +
> >  5 files changed, 505 insertions(+)
Is there any concern or objection? If no, I will make requested changes and 
apply this version.

Thanks!
Ruiling

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers

2019-12-11 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Max
> Dmitrichenko
> Sent: Wednesday, November 20, 2019 3:04 PM
> To: FFmpeg development discussions and patches 
> Cc: Li, Zhong 
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
> 
> On Sun, Sep 29, 2019 at 3:19 AM Fu, Linjie  wrote:
> 
> > > -Original Message-
> > > From: Li, Zhong 
> > > Sent: Friday, September 13, 2019 00:05
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Cc: Fu, Linjie 
> > > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > > vaMapBuffer returns multiple buffers
> > >
> > > > From: ffmpeg-devel  On Behalf Of
> > > Linjie Fu
> > > > Sent: Friday, May 31, 2019 8:35 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Fu, Linjie 
> > > > Subject: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > > > vaMapBuffer returns multiple buffers
> > > >
> > > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> > > map
> > > > buffer for each slice.
The patch LGTM. But the above line of commit message seems not too much 
relevant.
Will remove this line of commit message and apply the patch if no objection.

Thanks!
Ruiling 

> > > >
> > > > Currently, assigning new buffer for pkt when multiple buffer returns
> > from
> > > > vaMapBuffer will cover the previous encoded pkt data and lead to encode
> > > issues.
> > > >
> > > > Iterate through the buf_list first to find out the total buffer size
> > needed for
> > > the
> > > > pkt, allocate the whole pkt to avoid repeated reallocation and memcpy,
> > > then copy
> > > > data from each buf to pkt.
> > > >
> > > > Signed-off-by: Linjie Fu 
> > > > ---
> > > > [v2]: allocate the whole pkt to avoid repeated reallocation and memcpy
> > > >
> > > >  libavcodec/vaapi_encode.c | 18 +-
> > > >  1 file changed, 13 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index
> > > > 2dda451..9c9e5dd 100644
> > > > --- a/libavcodec/vaapi_encode.c
> > > > +++ b/libavcodec/vaapi_encode.c
> > > > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > > *avctx,
> > > >  VAAPIEncodeContext *ctx = avctx->priv_data;
> > > >  VACodedBufferSegment *buf_list, *buf;
> > > >  VAStatus vas;
> > > > +int total_size = 0;
> > > > +uint8_t *ptr;
> > > >  int err;
> > > >
> > > >  err = vaapi_encode_wait(avctx, pic); @@ -505,15 +507,21 @@ static
> > int
> > > > vaapi_encode_output(AVCodecContext *avctx,
> > > >  goto fail;
> > > >  }
> > > >
> > > > +for (buf = buf_list; buf; buf = buf->next)
> > > > +total_size += buf->size;
> > > > +
> > > > +err = av_new_packet(pkt, total_size);
> > > > +ptr = pkt->data;
> > > > +
> > > > +if (err < 0)
> > > > +goto fail_mapped;
> > > > +
> > > >  for (buf = buf_list; buf; buf = buf->next) {
> > > >  av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > > > "(status %08x).\n", buf->size, buf->status);
> > > >
> > > > -err = av_new_packet(pkt, buf->size);
> > > > -if (err < 0)
> > > > -goto fail_mapped;
> > > > -
> > > > -memcpy(pkt->data, buf->buf, buf->size);
> > > > +memcpy(ptr, buf->buf, buf->size);
> > > > +ptr += buf->size;
> > > >  }
> > > >
> > > >  if (pic->type == PICTURE_TYPE_IDR)
> > > > --
> > > > 2.7.4
> > >
> > > LGTM
> >
> > Thanks for review.
> > A kindly ping.
> >
> > - linjie
> >
> 
> LGTM
> 
> regards
> Max
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 SIMD for filter_column()

2019-12-03 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> chen
> Sent: Tuesday, December 3, 2019 4:59 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86
> SIMD for filter_column()
> 
> comments inline in code
> 
> 
> At 2019-12-03 15:52:07, xuju...@sjtu.edu.cn wrote:
> >From: Xu Jun 
[...]
> >+
> >+cvtdq2ps m4, m4
> >+mulps m4, m0 ; sum *= rdiv
> >+addps m4, m1 ; sum += bias
> 
> >+addps m4, m5 ; sum += 0.5
> I don't know how about precision mismatch if we pre-compute (bias+0.5)
I think it is hard to prove it is safe to do pre-compute.

> 
> 
> >+cvttps2dq m4, m4
> >+packssdw m4, m4
> >+packuswb m4, m4
> >+movss [dstq + dst_offq], m4
> >+add c_offq, mmsize/4
> >+add dst_offq, mmsize/4
> >+
> >+add off16q, mmsize/4
> >+cmp off16q, widthq
> >+jl .loop16
> >+
> >+add widthq, rq
> >+cmp off16q, widthq
> >+jge .paraend
> >+
> 
> >+.loopr:
> no idea about this loop, if we can read beyond, we can reuse above SIMD
> code
Reuse above SIMD code may write to the memory that does not belong to this 
slice-thread.
IMO, the code to handle remainder columns is still necessary.

Ruiling
> 
> 
> >+xor sumd, sumd
> >+xor iq, iq
> >+.loopr_i:
> >+mov ciq, [ptrq + iq * gprsize]
> >+movzx rd, byte [ciq + c_offq]
> >+imul rd, [matrixq + 4*iq]
> >+add sumd, rd
> >+
> >+add iq, 1
> >+cmp iq, radq
> >+jl .loopr_i
> >+
> >+pxor m4, m4
> >+cvtsi2ss m4, sumd
> >+mulss m4, m0 ; sum *= rdiv
> >+addss m4, m1 ; sum += bias
> >+addss m4, m5 ; sum += 0.5
> >+cvttps2dq m4, m4
> >+packssdw m4, m4
> >+packuswb m4, m4
> >+movd sumd, m4
> >+mov [dstq + dst_offq], sumb
> >+add c_offq, 1
> >+add dst_offq, 1
> >+add off16q, 1
> >+cmp off16q, widthq
> >+jl .loopr
> >+
> >+.paraend:
> >+sub c_offq, widthq
> >+sub dst_offq, widthq
> >+add c_offq, strideq
> >+add dst_offq, dstrideq
> >+
> >+sub heightq, 1
> >+cmp heightq, 0
> >+jg .loopy
> >+
> >+.end:
> >+RET
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86 SIMD for filter_column()

2019-12-03 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> chen
> Sent: Wednesday, December 4, 2019 9:36 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86
> SIMD for filter_column()
> 
> 
> 
> At 2019-12-04 08:59:08, "Song, Ruiling"  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> chen
> >> Sent: Tuesday, December 3, 2019 4:59 PM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_convolution: add X86
> >> SIMD for filter_column()
> >>
> >> comments inline in code
> >>
> >>
> >> At 2019-12-03 15:52:07, xuju...@sjtu.edu.cn wrote:
> >> >From: Xu Jun 
> >[...]
> >> >+
> >> >+cvtdq2ps m4, m4
> >> >+mulps m4, m0 ; sum *= rdiv
> >> >+addps m4, m1 ; sum += bias
> >>
> >> >+addps m4, m5 ; sum += 0.5
> >> I don't know how about precision mismatch if we pre-compute (bias+0.5)
> 
> >I think it is hard to prove it is safe to do pre-compute.
> Agree, I also worried precision issue since float operator is execute order
> dependent.
> How about ROUNDPS?
Seems no exactly match.
> 
> 
> >
> >>
> >>
> >> >+cvttps2dq m4, m4
> >> >+packssdw m4, m4
> >> >+packuswb m4, m4
> >> >+movss [dstq + dst_offq], m4
> >> >+add c_offq, mmsize/4
> >> >+add dst_offq, mmsize/4
> >> >+
> >> >+add off16q, mmsize/4
> >> >+cmp off16q, widthq
> >> >+jl .loop16
> >> >+
> >> >+add widthq, rq
> >> >+cmp off16q, widthq
> >> >+jge .paraend
> >> >+
> >>
> >> >+.loopr:
> >> no idea about this loop, if we can read beyond, we can reuse above SIMD
> >> code
> >Reuse above SIMD code may write to the memory that does not belong to
> this slice-thread.
> 
> >IMO, the code to handle remainder columns is still necessary.
> 
> 
> Depends on algorithm & size,
> For example width=23
> Process #0 [0:15]
> Process #1 [7:22]
> Both of them is multiple of 16
Sounds interesting. But FFmpeg does not do like this now.
One question is will this get a penalty for writing to same address of memory 
(both are writing to 7-15) from different threads?

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> xuju...@sjtu.edu.cn
> Sent: Wednesday, November 27, 2019 10:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: xuju...@sjtu.edu.cn
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column
> operation for filter_column() to prepare for x86 SIMD.
> 
> From: Xu Jun 
> 
> In order to add x86 SIMD for filter_column(), I write a C function which
> processes 16 columns at a time.
> 
> Signed-off-by: Xu Jun 
> ---
>  libavfilter/vf_convolution.c  | 56 +++
>  libavfilter/x86/vf_convolution_init.c | 23 +++
>  2 files changed, 79 insertions(+)
> 
> diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
> index d022f1a04a..5291415d48 100644
> --- a/libavfilter/vf_convolution.c
> +++ b/libavfilter/vf_convolution.c
> @@ -520,6 +520,61 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
> int jobnr, int nb_jobs)
>  continue;
>  }
> 
> +if (mode == MATRIX_COLUMN && s->filter[plane] != filter_column){
> +for (y = slice_start; y < slice_end - 16; y+=16) {
Please take care of the coding style there should be white-space between 
variables and operators.
And also I think this piece of change make it harder to maintain, let's try to 
avoid code duplicate as much as we can.
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = radius * stride;
> +for (x = 0; x < radius; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, 16, radius,
> +dstride, stride);
> +}
> +s->setup[plane](radius, c, src, stride, radius, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
> +rdiv, bias, matrix, c, 16, radius,
> +dstride, stride);
> +for (x = sizew - radius; x < sizew; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, 16, radius,
> +dstride, stride);
> +}
> +}
> +if (y < slice_end){
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = radius * stride;
> +for (x = 0; x < radius; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, slice_end - y, radius,
> +dstride, stride);
> +}
> +s->setup[plane](radius, c, src, stride, radius, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
> +rdiv, bias, matrix, c, slice_end - y, radius,
> +dstride, stride);
> +for (x = sizew - radius; x < sizew; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, slice_end - y, radius,
> +dstride, stride);
> +}
> +}
> +}
> +else {
>  for (y = slice_start; y < slice_end; y++) {
>  const int xoff = mode == MATRIX_COLUMN ? (y - slice_start) * bpc 
> :
> radius * bpc;
>  const int yoff = mode == MATRIX_COLUMN ? radius * stride : 0;
> @@ -550,6 +605,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
> int jobnr, int nb_jobs)
>  dst += dstride;
>  }
>  }
> +}
> 
>  return 0;
>  }
> diff --git a/libavfilter/x86/vf_convolution_init.c
> b/libavfilter/x86/vf_convolution_init.c
> index d1e8c90ceb..6b1c2f0e9f 100644
> --- a/libavfilter/x86/vf_convolution_init.c
> +++ b/libavfilter/x86/vf_convolution_init.c
> @@ -34,6 +34,27 @@ void ff_filter_row_sse4(uint8_t *dst, int width,
>  const uint8_t 

Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S

2019-11-27 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Carl Eugen Hoyos
> Sent: Thursday, November 28, 2019 2:37 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
> 
> 
> 
> > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng :
> >
> >>>
> >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input for
> vaapi tone-mapping\n");
> >>> +return AVERROR(EINVAL);
> >>
> >> Shouldn't this also accept unknown trc?
> >> (With a warning)
> >
> > Sorry if I misunderstand "unknown trc". Did you mean the trc undefined by
> ffmpeg or the trc unsupported by the driver?
> 
> My question is:
> If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail?
> But shouldn’t the user be able to use the filter in this case?
Hi Carl,

I am not sure if assuming the input is using SMPTE2084 sounds more acceptable 
in case of unspecified? If yes, I think we can change as you suggested.
I suggested Xinpeng to follow the behavior of tonemap_opencl for such case, 
i.e. to fail explicitly for cases other than SMPTE2084. Because people may get 
incorrect color.

Ruiling
> 
> Thank you for the explanations, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate code block

2019-11-28 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Liu
> Steven
> Sent: Friday, November 29, 2019 7:42 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Liu Steven 
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate
> code block
> 
> 
> 
> > 在 2019年11月29日,上午2:48,Michael Niedermayer
>  写道:
> >
> > On Thu, Nov 28, 2019 at 11:26:24AM +0800, Steven Liu wrote:
> >>
> >>
> >>> 在 2019年11月28日,04:06,Michael Niedermayer
>  写道:
> >>>
> >>> mm-short.mpg
> >> Hi Michael,
> >>
> >>Where should i download the file mm-short.mpg?
> >
> > you can make it yourself, it is just:
> >
> > dd if=matrixbench_mpeg2.mpg of=mm-short.mpg count=4000
> 
> StevenLiu:dash StevenLiu$ find fate-suite -name matrixbench_mpeg2.mpg
> StevenLiu:dash StevenLiu$
> There have no file named matrixbench_mpeg2.mpg,
> I ask for the mpg file for: i want to know what contents of the mpg file, just
> video stream? audio stream? or other stream?
https://samples.ffmpeg.org/benchmark/testsuite1/

> 
> 
> Whatever, i will resubmit a new version patch, try to fix this problem.
> 
> >
> > db7c44ab3d2b75d6e61fe61b1a595b31  mm-short.mpg
> >
> 
> Thanks
> Steven
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S

2019-11-28 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Carl Eugen Hoyos
> Sent: Thursday, November 28, 2019 5:16 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
> 
> Am Do., 28. Nov. 2019 um 07:56 Uhr schrieb Song, Ruiling
> :
> 
> > > > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng
> :
> > > >
> > > >>>
> > > >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > > >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input
> for
> > > vaapi tone-mapping\n");
> > > >>> +return AVERROR(EINVAL);
> > > >>
> > > >> Shouldn't this also accept unknown trc?
> > > >> (With a warning)
> > > >
> > > > Sorry if I misunderstand "unknown trc". Did you mean the trc
> undefined by
> > > ffmpeg or the trc unsupported by the driver?
> > >
> > > My question is:
> > > If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail?
> > > But shouldn’t the user be able to use the filter in this case?
> >
> > I am not sure if assuming the input is using SMPTE2084 sounds more
> acceptable
> > in case of unspecified? If yes, I think we can change as you suggested.
> 
> (Me neither.)
> A warning could be shown instead of failing.
Adding a warning sound good idea. But in order to proceed the tone-mapping, a 
default input transfer-function need to be chosen, which I think we can use 
SMPTE2084 here.

Ruiling
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] avfilter: Add tonemap vaapi filter for H2S

2019-11-12 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Carl Eugen Hoyos
> Sent: Tuesday, November 12, 2019 5:52 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v1] avfilter: Add tonemap vaapi filter for
> H2S
> 
> Hi!
> 
> > Am 12.11.2019 um 17:59 schrieb Xinpeng Sun :
> >
> > It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> conversion
> > with tone-mapping. It supports HDR10 only as input temporarily.
> >
> > H2S: P010 -> NV12
> 
> No objection here but could you tell us if you (Intel) already have a plan how
> to deal with H2H?
Hi Carl,

I guess H2S would be much more useful than H2H. So I think it is ok to make H2S 
patch work well and acceptable.

Ruiling
> 
> Thank you for your effort, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1] avfilter: Add tonemap vaapi filter for H2S

2019-11-12 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Xinpeng Sun
> Sent: Tuesday, November 12, 2019 5:00 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Sun, Xinpeng ; Zhou, Zachary
> 
> Subject: [FFmpeg-devel] [PATCH v1] avfilter: Add tonemap vaapi filter for
> H2S
> 
> It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> conversion
> with tone-mapping. It supports HDR10 only as input temporarily.
> 
> H2S: P010 -> NV12
Have you tried P010 HDR to P010 SDR? Does it work? I think people may like use 
10bit SDR because it has more color details.

> 
> An example command to use this filter with vaapi codecs:
> FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -
> hwaccel_output_format vaapi \
> -i INPUT -vf 'tonemap_vaapi=h2s,hwdownload,format=nv12' -pix_fmt nv12 \
> -f rawvideo -y OUTPUT
> 
> Signed-off-by: Xinpeng Sun 
> Signed-off-by: Zachary Zhou 
> ---
>  doc/filters.texi   |  30 
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vaapi_vpp.c|   5 +
>  libavfilter/vf_tonemap_vaapi.c | 272
> +
>  5 files changed, 309 insertions(+)
>  create mode 100644 libavfilter/vf_tonemap_vaapi.c
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 6800124574..b1c466ba24 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -20754,6 +20754,36 @@ Convert HDR(PQ/HLG) video to bt2020-transfer-
> characteristic p010 format using li
>  @end example
>  @end itemize
> 
This should not be here. Please move above opencl video filters or start 
another chapter dedicated for vaapi accelerated video filters somewhere.
> +@section tonemap_vappi
> +
> +Perform HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> conversion with tone-mapping.
> +It maps the dynamic range of HDR10 content to the SDR content.
> +It only accepts HDR10 as input temporarilly.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +@item type
> +Specify the tone-mapping operator to be used.
> +
> +Possible values are:
> +@table @var
> +@item h2s
> +Perform H2S(HDR to SDR), convert from p010 to nv12
> +@end table
> +
> +@end table
> +
> +@subsection Example
> +
> +@itemize
> +@item
> +Convert HDR video to SDR video from p010 format to nv12 format.
> +@example
> +-i INPUT -vf "tonemap_vaapi=h2s" OUTPUT
> +@end example
> +@end itemize
> +
>  @section unsharp_opencl
> 
>  Sharpen or blur the input video.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fce930360d..90a0e9945e 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -410,6 +410,7 @@ OBJS-$(CONFIG_TMIX_FILTER)   += vf_mix.o
> framesync.o
>  OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o colorspace.o
>  OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o
> colorspace.o opencl.o \
>  opencl/tonemap.o 
> opencl/colorspace_common.o
> +OBJS-$(CONFIG_TONEMAP_VAAPI_FILTER)  += vf_tonemap_vaapi.o
> vaapi_vpp.o
>  OBJS-$(CONFIG_TPAD_FILTER)   += vf_tpad.o
>  OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
>  OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER)  += vf_transpose_npp.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 7c1e19e1da..b2fb1f8a98 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -390,6 +390,7 @@ extern AVFilter ff_vf_tlut2;
>  extern AVFilter ff_vf_tmix;
>  extern AVFilter ff_vf_tonemap;
>  extern AVFilter ff_vf_tonemap_opencl;
> +extern AVFilter ff_vf_tonemap_vaapi;
>  extern AVFilter ff_vf_tpad;
>  extern AVFilter ff_vf_transpose;
>  extern AVFilter ff_vf_transpose_npp;
> diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
> index b5b245c8af..5776243fa0 100644
> --- a/libavfilter/vaapi_vpp.c
> +++ b/libavfilter/vaapi_vpp.c
> @@ -257,6 +257,11 @@ static const VAAPIColourProperties
> vaapi_colour_standard_map[] = {
>  { VAProcColorStandardSMPTE170M,   6,  6,  6 },
>  { VAProcColorStandardSMPTE240M,   7,  7,  7 },
>  { VAProcColorStandardGenericFilm, 8,  1,  1 },
> +
> +#if VA_CHECK_VERSION(2, 3, 0)
> +{ VAProcColorStandardExplicit,9,  16, AVCOL_SPC_BT2020_NCL},
> +#endif
> +
>  #if VA_CHECK_VERSION(1, 1, 0)
>  { VAProcColorStandardSRGB,1, 13,  0 },
>  { VAProcColorStandardXVYCC601,1, 11,  5 },
> diff --git a/libavfilter/vf_tonemap_vaapi.c b/libavfilter/vf_tonemap_vaapi.c
> new file mode 100644
> index 00..27ee17bf00
> --- /dev/null
> +++ b/libavfilter/vf_tonemap_vaapi.c
> @@ -0,0 +1,272 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will 

Re: [FFmpeg-devel] [PATCH V2 1/3] checkasm/vf_eq: add test for vf_eq

2019-09-24 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Li,
> Zhong
> Sent: Tuesday, September 24, 2019 2:34 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V2 1/3] checkasm/vf_eq: add test for
> vf_eq
> 
> > From: ffmpeg-devel  On Behalf Of
> Ting Fu
> > Sent: Wednesday, September 18, 2019 3:06 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH V2 1/3] checkasm/vf_eq: add test for
> vf_eq
> >
> > Signed-off-by: Ting Fu 
> > ---
> >  libavfilter/vf_eq.c   | 13 ---
> >  libavfilter/vf_eq.h   |  1 +
> >  tests/checkasm/Makefile   |  1 +
> >  tests/checkasm/checkasm.c |  3 ++
> >  tests/checkasm/checkasm.h |  1 +
> >  tests/checkasm/vf_eq.c| 79
> +++
[...]
> > +declare_func(void, EQParameters *param, uint8_t *dst, int dst_stride,
> > + const uint8_t *src, int src_stride, int w, int h);
> > +
> > +memset(src, 0, PIXELS);
> 
> Looks it is redundant with randomize_buffers() and make performance drop
Will remove and apply.
> 
> > +memset(dst_ref, 0, PIXELS);
> > +memset(dst_new, 0, PIXELS);
> > +randomize_buffers(src, PIXELS);
> > +ff_eq_init();
> > +
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

<    1   2