[FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86 optimized video scaling filter
Soft Works
softworkz at hotmail.com
Mon Jun 7 23:43:55 EEST 2021
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Monday, June 7, 2021 6:57 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86
> optimized video scaling filter
>
> Soft Works (12021-06-05):
> > 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.
>
> This is exactly what we should do. We should not have accepted code that
> links to non-free libraries in the first place.
While I respect and even understand your opinion, I don't share it. When there's a way to achieve so much better results, then I'd want to use it, just like hardware accelerations that are not always open source either. Surely, it makes sense to decide on a case-by-case basis.
Though, just blindly rejecting everything that isn't completely open, might cause some significant(!) fork to emerge that covers all these things, which gladly hasn't happened yet.
> > 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).
>
> The Libre software movement has achieved so much thanks to people who
> have rejected this kind of compromise. But now people are taking it for
> granted, and it loses ground to Open Source, where software giants get free
> work without giving anything in return beyond token contribution and quasi-
> proprietary code.
I don't think you could say that about Intel. They have open-sourced a huge amount of code in the recent years, they have more than a dozen developers that are making contributions to ffmpeg, so what you are saying may apply to others but not in this case.
IPP is huge and exists for a long time. It has formerly been a commercial product, and now it's free, hopefully open-sourced at some time - I'd second that.
What makes this a special case, is that IPP includes functions, each with many implementations, optimized for individual CPU models. This is something that a single or few open source developers couldn't easily replicate in a reasonable amount of time, at least not in the same detail and distinction between models, simply because nobody has access to that wide range of models to verify all these implementation on each model. Plus, there's has surely been a flow of internal knowledge into those implementations.
Nothing is impossible, but in this case I think that it's just not realistic to expect that this could ever be paralleled by another implementation.
That's why I'm all for including this.
softworkz
More information about the ffmpeg-devel
mailing list