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

Gyan Doshi ffmpeg at gyani.pro
Wed May 26 07:05:51 EEST 2021



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.

> 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.

Regards,
Gyan


More information about the ffmpeg-devel mailing list