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.
That's exactly what I said though? Making configure/make generate the
code at build time, so the generated code is not in the repo, only the
actual .cu file.
One problem with that is, that nvcc require cl.exe on Windows, it
doesn't work with gcc. So that would limit it to MSVC builds on Windows,
which is fine with me.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
