> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of myp...@gmail.com > Sent: Wednesday, May 22, 2019 11:14 AM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Cc: Jun Zhao <barryjz...@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.s...@intel.com> > wrote: > > > > > > > > > -----Original Message----- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Jun Zhao > > > Sent: Wednesday, May 22, 2019 12:29 AM > > > To: ffmpeg-devel@ffmpeg.org > > > Cc: Jun Zhao <barryjz...@tencent.com> > > > Subject: [FFmpeg-devel] [PATCH V1] lavfi/lut: Add slice threading support > > > > > > From: Jun Zhao <barryjz...@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 <barryjz...@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@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".
