[FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support

Song, Ruiling ruiling.song at intel.com
Wed May 22 06:24:20 EEST 2019



> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of mypopy at gmail.com
> Sent: Wednesday, May 22, 2019 11:14 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Cc: Jun Zhao <barryjzhao at tencent.com>
> Subject: Re: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading
> support
> 
> On Wed, May 22, 2019 at 11:03 AM Song, Ruiling <ruiling.song at intel.com>
> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> > > Of Jun Zhao
> > > Sent: Wednesday, May 22, 2019 12:29 AM
> > > To: ffmpeg-devel at ffmpeg.org
> > > Cc: Jun Zhao <barryjzhao at tencent.com>
> > > Subject: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support
> > >
> > > From: Jun Zhao <barryjzhao at tencent.com>
> > >
> > > Used the command for 1080p h264 clip as follow:
> > >
> > > a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
> > > b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null
> > >
> > > after enabled the slice threading, the fps change from:
> > >
> > > a). 144fps to 258fps (lutyuv)
> > > b). 94fps  to 153fps (lutrgb)
> > >
> > > in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
> > >
> > > Signed-off-by: Jun Zhao <barryjzhao at tencent.com>
> > > ---
> > >  libavfilter/vf_lut.c |  328 +++++++++++++++++++++++++++++++++------
> ----
> > > -------
> > >  1 files changed, 216 insertions(+), 112 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
> > > index c815ddc..61550ee 100644
> > > --- a/libavfilter/vf_lut.c
> > > +++ b/libavfilter/vf_lut.c
> > > @@ -337,13 +337,194 @@ static int config_props(AVFilterLink *inlink)
> > >      return 0;
> > >  }
> > >
> > > +struct thread_data {
> > > +    AVFrame *in;
> > > +    AVFrame *out;
> > > +
> > > +    int w;
> > > +    int h;
> > > +};
> >
> > I think it's better to refine the patch to avoid duplicating code, the exiting
> source code has been copy-pasted too much.
> > Maybe we just need lut_packed() and lut_planar(). For 8/16 variation, I
> think it is easy to add one field( like "int is_16bit;")in thread_data to solve it.
> Ha, in fact, they are come from origin code, and I noticed the code
> redundancy in origin code, as my plan, I plan to split with 2 steps:
> step 1: enabling the slice thread, it's will help to review + test (as
> this patch)
> step 2: refine the code redundancy, (the next round patch).
> 
>  So you want to combine step 1 and step 2 as one patch ? Thanks.
Yes, I don't see much benefit of split it into 2 steps. I prefer reviewing clean code.

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


More information about the ffmpeg-devel mailing list