> I've spent a lot more time looking at the nvidia patch, but from a
> quick look through Timo's version, I'd say the following:
> 
> * Timo's is more concise but not as feature complete.
> * nvidia one has windows support
> * The nvidia patch doesn't handle b-frames correctly, but I wrote a
>   fix patch for them. I'm not sure whether Timo's works correctly
> * Timo's looks like it will handle interlaced input correctly. Nvidia
>   definitely does not.
> * nvidia one implements argument compatibility with x264 - so it uses
>   the same args as much as possible - it even does preset/tune mapping.
>   I think this is pretty nice.
> 
> The main issue with the nvidia patch, as it exists today, is that they
> have not put any licence header on the files at all - but I've told
> them they need to do that, and asked Stephen Warren if he can help them
> out. The other slight complexity is that it requires cuda.h (Timo seems
> to have avoided that by independently defining the necessary constants
> but you need even more of cuda.h for the windows support). But
> nvEncoderAPI.h is already so awkward (restrictive license, not properly
> distributed) that an extra header isn't any more inconvenient.

My implementation also works fine on Windows. (Tested is with MSVC,
MinGW and Cygwin)
The required functions from CUDA are minimal, and i just dynamicaly load
them, avoiding any (linked) external dependencies except the nvEncodeAPI.h

The main difference is that they support way more features, but they
seem to need an intermediate library, while mine is now just a single
new C file, which needs one header from the nvenc SDK.


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to