[FFmpeg-devel] Patch for CUDA Scale Filter

[wm4]

On Mon, 17 Apr 2017 12:22:00 +0200
Timo Rothenpieler <timo at rothenpieler.org> wrote:

> Am 17.04.2017 um 08:59 schrieb Yogender Gupta:
> >>> Please find attached a CUDA based scale filter. This filter will be a starting point to add other CUDA based filters. The filter supports 420-8, 420-10, 444-8, 444-10 formats and will help to do complete 10-bit HW accelerated transcoding when using >> CUVID.
> >>> Currently the filter requires a manual step of generating the PTX files. The commands for generating the PTX files have been put in build.bat inside the CUDA folder that has been created as a subfolder within libavfilter.
> >>> There is an existing scale_npp filter however that filter supports only 8 bit and has lower performance than the current one.  
> > 
> > Are there any plans to include this in the repo. Anything that I can support here to make it worthy.
> > 
> > Thanks,
> > Yogender  
> 
> I'm generally in favor of adding CUDA based filtering, there's a lot of 
> nice stuff that could be done that way.
> 
> But there is one big issue with this approach:
> 
> Having to run a .bat file prior to building isn't really nice, and not 
> something I and some other people on IRC would like to see in ffmpeg.
> 
> Instead, it would be nice if configure/make would learn how to handle 
> .cu files, converting them straight to an object-file.
> My idea for this would be to teach the Makefiles about .cu files, and 
> using a shell script as their compiler.
> That script can then call nvcc and include the ptx2c functionality, and 
> additionally also calls the designated C compiler, so for the build 
> system it converts .cu to .o.
> 
> Also, due to these kind of filters having to include cuda.h, they need 
> to be put behind --enable-nonfree in configure.
> 
> That's what I have in mind so far. I didn't have time for a full review 
> of the code yet, so can't say much about the filter itself.

I'm against. Building the "script" seems pretty terribly complicated,
and adding generated code is usually not what we do in this project.
This is probably done better with a d3d11 video scale filter, although
I'm not sure about the tradeoffs yet.