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
signature.asc
Description: PGP signature
_______________________________________________ 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".
