On Sat, Nov 29, 2014 at 10:29:50AM -0800, Philip Langdale wrote: > On Sat, 29 Nov 2014 19:00:02 +0100 > Timo Rothenpieler <t...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel