On 12/10/15, Philip Langdale wrote:
> On 2015-12-09 21:34, wm4 wrote:
>> On Mon, 7 Dec 2015 19:34:20 +0100
>> Timo Rothenpieler wrote:
>>
>>> > I don't remember if this was discussed when avisynth and other headers
>>> > where included, but what's the advantage of directly including the
>>> > hea
On 10 Dec, Philip Langdale wrote :
> >Are we really talking about including a huge 3rd party header because
> >distros are so lazy? What's next, do we add Windows headers to the
> >FFmpeg tree, because MinGW lags severely behind the newest definitions
> >like HEVC DXVA support?
>
> Admittedly, we
On 10.12.2015 20:37, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> Using the header, one could create a dummy libfoo.so containing only
>> stub functions.
>
> Exactly.
>
>> I don't think the FSF would agree [1].
>
> They do not make the law.
Neither do
Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> Using the header, one could create a dummy libfoo.so containing only
> stub functions.
Exactly.
> I don't think the FSF would agree [1].
They do not make the law. Claiming that the GPL enforces more than it can is
obviously their ga
On 10.12.2015 19:48, Matt Oliver wrote:
> On 11 December 2015 at 04:23, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 10.12.2015 17:42, Matt Oliver wrote:
>>> Im not sure that Debian not including libcuda is a valid argument for it
>>> not being a system library as thats j
On 10.12.2015 19:03, Nicolas George wrote:
> Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> I'm not sure it's that easy. If that were correct, it would become
>> GPL-compatible to distribute a GPL-licensed program linked with a
>> proprietary library by simply inserting a MIT lice
On 11 December 2015 at 04:23, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 10.12.2015 17:42, Matt Oliver wrote:
> >>
> >> What is a system library depends on the system.
> >> For example, Debian (main) does not even include libcuda or
> >> libnvidia-encode, so they
Le decadi 20 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> I'm not sure it's that easy. If that were correct, it would become
> GPL-compatible to distribute a GPL-licensed program linked with a
> proprietary library by simply inserting a MIT licensed header in the middle.
But yes, it is that
On 10.12.2015 17:42, Matt Oliver wrote:
>>
>> What is a system library depends on the system.
>> For example, Debian (main) does not even include libcuda or
>> libnvidia-encode, so they certainly cannot be system libraries there.
>
>>
>
> Im not sure that Debian not including libcu
On 10.12.2015 17:34, Hendrik Leppkes wrote:
> Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" <
> andreas.cadhal...@googlemail.com>:
>> If that's the only thing that allows distribution of compiled nvenc.c,
>> it shouldn't be enabled by default.
>>
>
> I don't mind disabling it by default, if that
>
>
> I don't mind disabling it by default, if that alleviates some concerns.
>
One caveat to my previous comments is that just like avisynth I think that
nvenc should be disabled by default aswell.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
Am 10.12.2015 17:10 schrieb "Andreas Cadhalpun" <
andreas.cadhal...@googlemail.com>:
>
> On 10.12.2015 16:49, Hendrik Leppkes wrote:
> > On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
> > wrote:
> >> The GPL-3 requires that the 'Corresponding Source' of the distributed
object code
> >> is also
>
> > >>> What is a system library depends on the system.
> > >>> For example, Debian (main) does not even include libcuda or
> > >>> libnvidia-encode, so they certainly cannot be system libraries there.
> > >>
>
Im not sure that Debian not including libcuda is a valid argument for it
not being a
On 10.12.2015 16:49, Hendrik Leppkes wrote:
> On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
> wrote:
>> The GPL-3 requires that the 'Corresponding Source' of the distributed object
>> code
>> is also distributed. This is defined as [1]:
>> The “Corresponding Source” for a work in object code
On Thu, Dec 10, 2015 at 4:25 PM, Andreas Cadhalpun
wrote:
> On 10.12.2015 15:18, Philip Langdale wrote:
>> On 2015-12-10 06:05, Andreas Cadhalpun wrote:
>>> On 09.12.2015 17:38, Hendrik Leppkes wrote:
On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler
wrote:
> If I understand carl r
On 10.12.2015 15:18, Philip Langdale wrote:
> On 2015-12-10 06:05, Andreas Cadhalpun wrote:
>> On 09.12.2015 17:38, Hendrik Leppkes wrote:
>>> On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler
>>> wrote:
If I understand carl right, the question is not about the header, but
about if dlop
On 2015-12-09 21:34, wm4 wrote:
On Mon, 7 Dec 2015 19:34:20 +0100
Timo Rothenpieler wrote:
> I don't remember if this was discussed when avisynth and other headers
> where included, but what's the advantage of directly including the
> header and burden the FFmpeg sources, rather than asking th
On 2015-12-10 06:05, Andreas Cadhalpun wrote:
On 09.12.2015 17:38, Hendrik Leppkes wrote:
On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler
wrote:
If I understand carl right, the question is not about the header, but
about if dlopen'ing a non-free library, the CUDA and NVENC ones in
this
cas
On 09.12.2015 17:38, Hendrik Leppkes wrote:
> On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler
> wrote:
>> If I understand carl right, the question is not about the header, but
>> about if dlopen'ing a non-free library, the CUDA and NVENC ones in this
>> case, makes ffmpeg non-free, or if they a
On Wed, Dec 9, 2015 at 5:33 PM, Timo Rothenpieler wrote:
Should fall under the system library stuff the GPL defines.
>>>
>>> I may misunderstand (I am not a native speaker) but the word
>>> "should" imo indicates that you cannot commit your patch.
>>>
>>
>> The header is licensed rather liber
>>> Should fall under the system library stuff the GPL defines.
>>
>> I may misunderstand (I am not a native speaker) but the word
>> "should" imo indicates that you cannot commit your patch.
>>
>
> The header is licensed rather liberally and doesn't actually link
> against anything, I don't see i
On Wed, Dec 9, 2015 at 3:14 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> On Monday 07 December 2015 07:37:21 pm Timo Rothenpieler wrote:
>> > On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote:
>> >> Nvidia finaly decided to put a propper MIT license on their nvenc
>> >> header, so it can be
>> Should fall under the system library stuff the GPL defines.
>
> I may misunderstand (I am not a native speaker) but the word
> "should" imo indicates that you cannot commit your patch.
Guess why I sent it here first...
> Sorry, Carl Eugen
> ___
> f
Hi!
On Monday 07 December 2015 07:37:21 pm Timo Rothenpieler wrote:
> > On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote:
> >> Nvidia finaly decided to put a propper MIT license on their nvenc
> >> header, so it can be included, removing any external dependencies for
> >> nvenc and m
On Mon, 7 Dec 2015 19:34:20 +0100
Timo Rothenpieler wrote:
> > I don't remember if this was discussed when avisynth and other headers
> > where included, but what's the advantage of directly including the
> > header and burden the FFmpeg sources, rather than asking the user to
> > download them i
> On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote:
>> Nvidia finaly decided to put a propper MIT license on their nvenc header,
>> so it can be included, removing any external dependencies for nvenc and
>> making it no longer require the non-free flag.
>
> Please do not apply (yet)!
> I don't remember if this was discussed when avisynth and other headers
> where included, but what's the advantage of directly including the
> header and burden the FFmpeg sources, rather than asking the user to
> download them in case of need?
The nvenc sdk isn't exactly a common thing that dist
On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote:
> Nvidia finaly decided to put a propper MIT license on their nvenc header,
> so it can be included, removing any external dependencies for nvenc and
> making it no longer require the non-free flag.
Please do not apply (yet)!
> +NVEN
On 12/7/2015 3:09 PM, Timo Rothenpieler wrote:
>>> @@ -1603,6 +1603,7 @@ CONFIG_LIST="
>>> memalign_hack
>>> memory_poisoning
>>> neon_clobber_test
>>> +nvenc
>>
>> You forgot to remove nvenc from EXTERNAL_LIBRARY_LIST
>
> Yep, forgot about that.
>
>>> +case $target_os in
>>> +
On date Monday 2015-12-07 14:53:22 -0300, James Almer encoded:
> On 12/7/2015 11:14 AM, Timo Rothenpieler wrote:
> > Nvidia finaly decided to put a propper MIT license on their nvenc header, so
> > it can be included, removing any external dependencies for nvenc and
> > making it no longer require
>> @@ -1603,6 +1603,7 @@ CONFIG_LIST="
>> memalign_hack
>> memory_poisoning
>> neon_clobber_test
>> +nvenc
>
> You forgot to remove nvenc from EXTERNAL_LIBRARY_LIST
Yep, forgot about that.
>> +case $target_os in
>> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
>> +
On 12/7/2015 11:14 AM, Timo Rothenpieler wrote:
> Nvidia finaly decided to put a propper MIT license on their nvenc header, so
> it can be included, removing any external dependencies for nvenc and
> making it no longer require the non-free flag.
>
> nvenc.h is the original nvEncodeApi.h from the
32 matches
Mail list logo
