[FFmpeg-devel] [PATCH] lavfi: add lumakey_opencl filter

[James Almer]

On 7/27/2018 7:22 AM, Danil Iashchenko wrote:
> Add lumakey_opencl filter. Behaves like existing lumakey filter.
> 
> ---
>  
> On Wed, Jul 25, 2018 at 10:50:43AM -0300, James Almer wrote:
>>> On 7/25/2018 9:13 AM, Danil Iashchenko wrote:
>>>> Add lumakey_opencl filter. Behaves like existing lumakey filter.
>>>
>>> Isn't it possible to keep each of these new OpenCL filters as an
>>> optional codepath within the C version, using an AVOption like "opencl"
>>> or "hwaccel" to toggle one or another? Or maybe autodetected depending
>>> on the filter chain and/or input pix_fmt?
>>>
>>> I'm asking because it's getting too crowded. We also have some vaapi and
>>> qsv duplicate filters, and once we start committing filters using the
>>> upcoming Vulkan hwcontext the same way, we may also end up introducing
>>> yet another hardware specific variant for each of these.
>>>
> 
>>> In libavcodec the hwaccels are seamlessly integrated into supported
>>> decoders. This has been favored over separate full stream hardware
>>> decoders where possible for the above reasons. It would be ideal to
>>> achieve the same with libavfilter.
> 
>> i am in favor of this design as well. The user should not need to have
>> to know about and manage manually GPU optimizations.
> 
>> thx
> 
> Hi! I am GSoC student and I still have some tasks before the program ends. 
> Also my mentor said:
>  <jkqxz> IMO don't think about it now, there isn't that much time left.
>  <jkqxz> I looked at doing last year (when converting to the current structure) and concluded that it's not really sane to do.
>  <jkqxz> The _opencl versions of filters operate completely differently, so while some code for setup can be shared putting them in the same filter doesn't really make sense.
> 
> Thanks, Danil.

Fair enough, i wasn't aware this was for GSoC, and this kind of change
(assuming it's doable) would definitely take a while, so it can wait.