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
On 2014-12-10 15:17, Michael Niedermayer wrote:
On Sat, Nov 29, 2014 at 10:29:50AM -0800, Philip Langdale wrote:
[...]
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
Le septidi 7 frimaire, an CCXXIII, Timo Rothenpieler a écrit :
Done that primarily to keep things cleaned up and easier to read.
Can as well put it all in one huge file.
IMHO, your choice in the end.
Propably, will split that out when i get to it.
Thanks.
Most of this code is ported from a
On Sat, Nov 29, 2014 at 12:13:18PM +0100, Timo Rothenpieler wrote:
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
On 29 Nov 2014 03:13, Timo Rothenpieler t...@rothenpieler.org wrote:
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
BTW, can you verify that interlaced encoding works for
you? I get initialization errors back from the hardware.
Doesn't work for me either. It looks like it's not (yet?) supported and
just available in the API.
signature.asc
Description: OpenPGP digital signature
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
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
Did some refactoring, now using a dynamic ring-buffer for both the
surface lists as well as the timestamp list.
There should be no thread safety problem anymore, as there are no
non-constant static global variables anymore.
I think i addressed most of the issues now, new patch is attached.
On Sun, 30 Nov 2014 00:04:37 +0100
Timo Rothenpieler t...@rothenpieler.org wrote:
Did some refactoring, now using a dynamic ring-buffer for both the
surface lists as well as the timestamp list.
There should be no thread safety problem anymore, as there are no
non-constant static global
On Sat, 29 Nov 2014 15:52:00 -0800
Philip Langdale phil...@overt.org wrote:
On Sun, 30 Nov 2014 00:04:37 +0100
Timo Rothenpieler t...@rothenpieler.org wrote:
Did some refactoring, now using a dynamic ring-buffer for both the
surface lists as well as the timestamp list.
There should
On Wed, 26 Nov 2014 11:21:26 +0100
Timo Rothenpieler t...@rothenpieler.org wrote:
This patch adds support for encoding with Nvidia NVENC on Windows and
Linux.
I'm not sure if this needs to be flagged as nonfree. As far as I'm
aware, it should not affect how the resulting binaries can be
On Fri, Nov 28, 2014 at 10:30:24AM -0800, Philip Langdale wrote:
On Wed, 26 Nov 2014 11:21:26 +0100
Timo Rothenpieler t...@rothenpieler.org wrote:
This patch adds support for encoding with Nvidia NVENC on Windows and
Linux.
I'm not sure if this needs to be flagged as nonfree. As far
On Sat, 29 Nov 2014 00:51:21 +0100
Michael Niedermayer michae...@gmx.at wrote:
For what it's worth, some engineers at Nvidia are also working on an
nvenc implementation for ffmpeg. That initial work is here:
https://github.com/agathah/ffmpeg_libnvenc
whats the difference in
I haven't looked in detail, but this doesn't seem like a good idea to me.
For example it can't handle having different encoders using different
cards/hardware.
I don't know what other options there might be, maybe this is the best, but it
seems not particularly good.
The only other option
On 26 Nov, Nicolas George wrote :
Le sextidi 6 frimaire, an CCXXIII, Hendrik Leppkes a écrit :
Thats just wrong. There is not one line of proprietary/non-free code that
gets included or linked in libavcodec.
(IANAL)
I do not think it works that way. You could apply the same reasoning
Timo Rothenpieler timo at rothenpieler.org writes:
I'm not sure if this needs to be flagged as nonfree.
Please mark it as non-free, the header clearly says
that it must not be used for open-source software.
Please use tools/patcheck on your patchfile: It shows
many issues most of which you
On Wed, Nov 26, 2014 at 11:38 AM, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Timo Rothenpieler timo at rothenpieler.org writes:
I'm not sure if this needs to be flagged as nonfree.
Please mark it as non-free, the header clearly says
that it must not be used for open-source software
Where
Please mark it as non-free, the header clearly says
that it must not be used for open-source software.
It only says not to distribute the header, the compiled binary and the
code using it should be free to distribute.
Please use tools/patcheck on your patchfile: It shows
many issues most of
Timo Rothenpieler timo at rothenpieler.org writes:
Please mark it as non-free, the header clearly says
that it must not be used for open-source software.
It only says not to distribute the header, the
compiled binary and the code using it should be free
to distribute.
I cannot read it
I cannot read it like this but I am not a native
speaker.
Maybe you could mark it as non-free until the FSF
tells us their interpretation?
Allright, new patch is attached.
ff_nvenc_encoder is missing pix_fmts afaict but
consider waiting for a real review.
Yes, that's intended.
It uses
On Wed, Nov 26, 2014 at 2:35 PM, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Timo Rothenpieler timo at rothenpieler.org writes:
Please mark it as non-free, the header clearly says
that it must not be used for open-source software.
It only says not to distribute the header, the
compiled
Le sextidi 6 frimaire, an CCXXIII, Hendrik Leppkes a écrit :
Thats just wrong. There is not one line of proprietary/non-free code that
gets included or linked in libavcodec.
(IANAL)
I do not think it works that way. You could apply the same reasoning when
linking a proprietary software with a
On 26.11.2014, at 14:58, Timo Rothenpieler t...@rothenpieler.org wrote:
I cannot read it like this but I am not a native
speaker.
Maybe you could mark it as non-free until the FSF
tells us their interpretation?
Allright, new patch is attached.
ff_nvenc_encoder is missing pix_fmts afaict
24 matches
Mail list logo
