[FFmpeg-devel] [PATCH 10/10] lavfi/vf_scale: pass the thread count to the scaler

[Michael Niedermayer]

On Mon, Aug 30, 2021 at 10:34:18AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-08-29 22:22:04)
> > On Sun, Aug 29, 2021 at 06:48:36PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2021-08-09 22:30:06)
> > > > On Sun, Aug 08, 2021 at 07:29:41PM +0200, Anton Khirnov wrote:
> > > > > ---
> > > > >  libavfilter/vf_scale.c | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > > > > index b62fb37d4b..14e202bf77 100644
> > > > > --- a/libavfilter/vf_scale.c
> > > > > +++ b/libavfilter/vf_scale.c
> > > > > @@ -542,6 +542,7 @@ static int config_props(AVFilterLink *outlink)
> > > > >              av_opt_set_int(*s, "sws_flags", scale->flags, 0);
> > > > >              av_opt_set_int(*s, "param0", scale->param[0], 0);
> > > > >              av_opt_set_int(*s, "param1", scale->param[1], 0);
> > > > > +            av_opt_set_int(*s, "threads", ff_filter_get_nb_threads(ctx), 0);
> > > > >              if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
> > > > >                  av_opt_set_int(*s, "src_range",
> > > > >                                 scale->in_range == AVCOL_RANGE_JPEG, 0);
> > > > > -- 
> > > > > 2.30.2
> > > > 
> > > > breaks:
> > > > ./ffmpeg -i ~/tickets/1012/IV50_random_points.avi  -threads 5 -y file1012.avi
> > > > 
> > > > it contains horizontal bright green lines
> > > 
> > > Should be fixed with the updated patches I sent just now.
> > > 
> > 
> > > That said, I think the special 410->420 scaler should be dropped - its
> > > output fundamentally depends on how the slices are submitted. Given that
> > 
> > hmm, iam not sure i understand the issue you describe.
> > Is this because the 410->420 scaler interpolates the chroma and to do so
> > it has to handle the image borders differently?
> 
> It handles _slice_ borders differently, not image borders. So the result
> depends on how the image is partitioned into slices.
> 

> I am not familiar with the generic scaler code, but it seems independent
> of this partitioning, otherwise the threaded scaling tests would fail.

the generic scaler simply stores the data originating from the previous slice
(generally after the horizontal scaler)

the 410->420 one probably should 
* store the one chroma line too somewhere
* initialize it to the first image line
* simplify all the 410->420 code so it always uses a pointer to the previous
  line either from the buffer or if available straight from the input image

It seems not worth for just 410->420, and i agree but the same could
be used for 420->444 and others which would have the same problem if one
wanted to do higher quality chroma interpolation in the unscaled special
converters

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210830/349f8875/attachment.sig>