[FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86 optimized video scaling filter

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Gyan Doshi
> Sent: Wednesday, May 26, 2021 6:06 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86
> optimized video scaling filter
> 
> 
> 
> On 2021-05-25 20:17, Hendrik Leppkes wrote:
> > On Tue, May 25, 2021 at 4:27 PM Gyan Doshi <ffmpeg at gyani.pro> wrote:
> >>
> >>
> >> On 2021-05-25 18:40, Nicolas George wrote:
> >>> Zhislina, Victoria (12021-05-25):
> >>>> While you are right that IPP is not GPL based and is closed source
> >>>> currently (but free for any commercial usage) and therefore does
> >>>> require --enable-nonfree, I'm sorry to mention that you are not
> >>>> right about "doing the same but faster". If you read my commit
> >>>> message you could see that it:
> >>>> Introduces superscaling interpolation method for video downscale.
> >>>> Adds antialiasing option to linear, cubic and lanczos interpolation.
> >>>>
> >>>> Moreover, IPP has 100-s of functions that could be added to ffmeg
> processing in the future.
> >>>> One more thing to mention - when you say "one single platform" it
> >>>> is
> >>>> x86 that undoubtedly covers top part of video processing market.
> >>>> Such filter creation request comes from one of the top ISVs in this
> market.
> >>> So, are you working on getting this library GPL-compatible? Notify
> >>> us once it's done.
> >>>
> >>> But there is no way we will accept code for a non-libre library
> >>> coming from the company that made the library in the first place.
> >>> That would be allowing freeloaders.
> >> Put it to a vote instead of one or a few developers declaring it NAK.
> >>
> > No developer has even proposed an actual counter argument yet (except
> > the submitter, of course), so there hasn't even been disagreement,
> > which would be the basis for a vote.
> 
> The disagreement is that patches should not be rejected on policy or
> philosophical grounds by one or a few developers.

And I agree to that disagreement. Also we shouldn't start acting as if the nonfree category wouldn't exist at all and everything that would fall into that category would suddenly no longer be acceptable.

> 
> > External libraries should be put under extra scrutiny, because in many
> > cases they don't necessarily serve the project - perhaps even the
> > opposite as it can slow down work on the native component in favor of
> > the external one being used.
> 
> No one's announced that they are working on a native implementation of
> the specific features this library offers. Most development nowadays is bug
> fixes and code/API sanitation.
> In practice, rejecting this lib is  rejecting those features.

Strong +1 on that!

If there's an open source or native implementation available, this should always receive precedence, but otherwise it's not a valid argument IMO to reject based on some fictional future (= someday, somebody might contribute a native implementation).

An implementation providing a benefit as huge as this, shouldn't be ignored IMO.

softworkz