> I'm not quite sure of what I think of this software/opencl hybrid > approach. On one hand, it's good that they share the "user interface" > (options etc.). On the other hand, the OpenCL part duplicates the > entire actual filter code. And unlike with asm, there's no good way to > test that they do the same thing. Also, the amount of OpenCL > boilerplate looks a bit high, considering that it already uses shared > OpenCL utility code. > > But since there are already 2 other filters which do this, there's not > much of a reason to reject this, assuming it works and it's reasonably > equivalent to software filtering.
Yes, it's not exactly pretty. I thought about ways to add more abstraction, but most filters are way to different in how they work and what parameters they require. If more simple filters gain OpenCL support, it should be possible to add a basic "Run CL kernel on frame" abstraction which reduces the amount of boilerplate needed.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
