On Wed, Dec 10, 2014 at 03:37:27PM -0800, Philip Langdale wrote:
> 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 li
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 lon
On Sat, Nov 29, 2014 at 10:29:50AM -0800, Philip Langdale wrote:
> On Sat, 29 Nov 2014 19:00:02 +0100
> Timo Rothenpieler wrote:
>
> > > does supporting these additional features need the extra complexity
> > > that the nvidia version has ?
> > > or could these features be added into your version
On Sat, 29 Nov 2014 15:52:00 -0800
Philip Langdale wrote:
> On Sun, 30 Nov 2014 00:04:37 +0100
> Timo Rothenpieler 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 a
On Sun, 30 Nov 2014 00:04:37 +0100
Timo Rothenpieler 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 variables anymore.
>
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.
commit
On Sat, 29 Nov 2014 19:00:02 +0100
Timo Rothenpieler 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 nvidi
> 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
> 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
_
On 29 Nov 2014 03:13, 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 nv
On 29 Nov 2014 03:45, Nicolas George wrote:
>
> 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 ou
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
On Thu, Nov 27, 2014 at 05:00:22PM +0100, Timo Rothenpieler wrote:
> Refactored the code even more now, new, tested, patch is attached
> and on github.
>
> The patch is ontop of my other patch that fixes the order in configure.
> Changelog |1
> configure |6
>
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 fro
> 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
> fi
On Sat, 29 Nov 2014 00:51:21 +0100
Michael Niedermayer 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 features bet
On Fri, Nov 28, 2014 at 10:30:24AM -0800, Philip Langdale wrote:
> On Wed, 26 Nov 2014 11:21:26 +0100
> Timo Rothenpieler 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
> >
On Wed, 26 Nov 2014 11:21:26 +0100
Timo Rothenpieler 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
> redistributed.
>
Am 27.11.2014 14:29 schrieb "Jean-Baptiste Kempf" :
>
> 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)
> >
Refactored the code even more now, new, tested, patch is attached and on
github.
The patch is ontop of my other patch that fixes the order in configure.
commit 2b26ed5562911f39a52ef00942003a52ea06640b
Author: Timo Rothenpieler
Date: Wed Nov 26 11:08:11 2014 +0100
Add NVENC encoder
diff
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 reas
Is it necessary to split the _api part in a separate file? The whole code is
a bit large, but still manageable, and merging the files would avoid some
headers overhead.
Done that primarily to keep things cleaned up and easier to read. Can as
well put it all in one huge file.
I think moving t
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 woul
On 26.11.2014, at 14:58, Timo Rothenpieler 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 but
>> co
Le sextidi 6 frimaire, an CCXXIII, Timo Rothenpieler a écrit :
> It uses init_static_data to dynamicaly ask the nvidia driver for the
> supported pixel formats instead.
It means it will try to load and init the library whenever libavcodec is
used, even if this specific encoder is not used. For a l
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 Wed, Nov 26, 2014 at 2:35 PM, Carl Eugen Hoyos wrote:
> Timo Rothenpieler 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 a
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 init_s
Timo Rothenpieler 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 i
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
On Wed, Nov 26, 2014 at 11:38 AM, Carl Eugen Hoyos wrote:
> Timo Rothenpieler 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 does it say that?
Timo Rothenpieler 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 should
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 redistributed.
The only dependency this has is the nvEncodeAPI.h from the NVENC SDK,
wh
33 matches
Mail list logo
