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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
