> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Monday, June 7, 2021 6:57 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> de...@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
_______________________________________________
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".

Reply via email to