[FFmpeg-devel] [PATCH] Add NVENC encoder

[Michael Niedermayer]

On Sat, Nov 29, 2014 at 10:29:50AM -0800, Philip Langdale wrote:
> On Sat, 29 Nov 2014 19:00:02 +0100
> Timo Rothenpieler <timo at rothenpieler.org> wrote:
> 
> > > does supporting these additional features need the extra complexity
> > > that the nvidia version has ?
> > > or could these features be added into your version while keeping its
> > > simplicity ? (note do not copy any code from the nvidia one as its
> > > not redistriutable nor *GPL compatible with the current license
> > > headers)
> > 
> > I haven't even looked at their code for quite exactly that reason.
> > The primary problem with NVENC is, that there is only very poor
> > documentation available, so I can only implement stuff based on
> > reading the header and experimenting with the API and the available
> > examples. NVIDIA employees clearly are in a better position for this,
> > as they most likely have a much larger insight into how NVENC works
> > internaly. I'm quite sure all of their features could be added to my
> > version.
> 
> I'm already 'polluted' until they correct their licensing, but I can at
> least describe what they have.
> 
> The main piece of complexity in their implementation is they have an
> additional abstraction layer between the ffmpeg encoder implementation
> and the nvenc API. So this layer 'insulates' the two APIs. From a
> licensing point of view it's meaningless, but I think that's the reason
> why it exists, based on a brief email exchange with them. If that was
> squashed, it would make theirs more straight forward. There's also a
> bunch of utility code that handles argument mapping between x264 args
> and nvenc args. As I've written elsewhere - I think this is a very
> useful thing to do, as people are, broadly, familiar with how to tell
> x264 to do stuff.
> 
> And as I mentioned before, they have a directx linked initialisation
> path as an alternative to the cuda one. I'm not sure what conditions
> that would be more useful under, but it's documented in the SDK.
> 
> Hopefully, they will respond positively on Monday and will get engaged
> here, and sort out their licensing so that we can all work on a single
> implementation.

monday passed long ago
what was their response ?
is there a reason to wait / not apply the patch in this thread ?


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141211/2dd741ee/attachment.asc>