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

[Michael Niedermayer]

On Mon, Aug 30, 2021 at 11:38:53AM +0200, Michael Niedermayer wrote:
> 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

Just to clarify, this is meant as a path forward for the bug with chroma
interpolation in the special converters which do or might want to use
chroma interpolation. 
Its not a review comment to the patchset(s)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier
-------------- 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/ba0f489c/attachment.sig>