> But before doing any of this, there has to be an agreement, whether or not
> the header should be included at all.
Of course.
Here's what I intend to do once I find some time again, which could take
a few days/weeks:
Split this up into three patches.
One that adds a check for NVENC Version 6,
On 15.12.2015 14:42, Timo Rothenpieler wrote:
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?
That would be OK for me.
> Or is putting that exception-text in nvenc.c enough to make enabling it
> by
On 15 Dec, Timo Rothenpieler wrote :
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?
I still don't understand why you want to fork this header into the
FFmpeg tree.
--
Jean-Baptiste Kempf
http://
So, to get somewhere with this, would everybody be ok if I change this
to remove the non-free marking, but keep it disabled by default for now?
Or is putting that exception-text in nvenc.c enough to make enabling it
by default viable?
signature.asc
Description: OpenPGP digital signature
___
Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> Is in a previous mail.
I looked and did not see it.
> I'm not continuing this silly conversation.
> You can look up the meaning of words in a dictionary.
This has nothing silly. Having the code of a codec interpret the bitstream
of a
On 12.12.2015 14:42, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> It does.
>
> [citation needed]
Is in a previous mail.
>> Multimedia files can't be executed, only decoded.
>
> Define the difference.
I'm not continuing this silly conversation.
You can
Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> It does.
[citation needed]
> Multimedia files can't be executed, only decoded.
Define the difference.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmp
On 12.12.2015 14:29, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> However, the (L)GPL has a rule that allows distribution of a
>> binary only together with the complete corresponding source code,
>> that also includes the source code of any dynamically loa
Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> However, the (L)GPL has a rule that allows distribution of a
> binary only together with the complete corresponding source code,
> that also includes the source code of any dynamically loaded
> library needed at run-time.
No, it does n
On 12.12.2015 14:03, Nicolas George wrote:
> Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
>> I don't agree as I have already explained previously.
>
> Fortunately, your arguments have no legal standing.
Neither have yours.
> The (L)GPL does not have a rule against distributing a
Le duodi 22 frimaire, an CCXXIV, Andreas Cadhalpun a écrit :
> I don't agree as I have already explained previously.
Fortunately, your arguments have no legal standing.
> Have a look at what some of the proprietary licenses require for distribution
> that has absolutely nothing to do with how the
On 12.12.2015 13:27, Philip Langdale wrote:
> On 2015-12-12 19:26, Andreas Cadhalpun wrote:
>> Anyway, I think your idea about a license exception would be a good solution.
>> We could add a special exception to nvenc.c, allowing its use with Nvidia's
>> blobs, something like [1]:
>>
>> In additio
On 12.12.2015 12:55, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
>> I am glad we agree that there is no difference (license-wise) if
>> a library is linked statically, dynamically or via dynamic
>> loading;-)
>
> You are, unfortunately, completely wrong.
On 2015-12-12 20:33, Nicolas George wrote:
Le duodi 22 frimaire, an CCXXIV, Philip Langdale a écrit :
it would be highly illogical to conclude that section 6/7 do not apply
to
the original code itself and that we need to construct a separate
entity
that does the combination for it to be licenc
Le duodi 22 frimaire, an CCXXIV, Philip Langdale a écrit :
> it would be highly illogical to conclude that section 6/7 do not apply to
> the original code itself and that we need to construct a separate entity
> that does the combination for it to be licence compliant.
It would be fairly illogical
On 2015-12-12 19:26, Andreas Cadhalpun wrote:
On 12.12.2015 11:35, Hendrik Leppkes wrote:
On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
wrote:
On 12.12.2015 10:50, Hendrik Leppkes wrote:
We should just add an exception into the license to explicitly allow
using it with the NVIDIA CUDA l
Le primidi 21 frimaire, an CCXXIV, Carl Eugen Hoyos a écrit :
> I am glad we agree that there is no difference (license-wise) if
> a library is linked statically, dynamically or via dynamic
> loading;-)
You are, unfortunately, completely wrong. It makes all the difference in the
world. Static li
On 12.12.2015 11:35, Hendrik Leppkes wrote:
> On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
> wrote:
>> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>>> We should just add an exception into the license to explicitly allow
>>> using it with the NVIDIA CUDA library and be done with this debate
On Sat, Dec 12, 2015 at 11:25 AM, Andreas Cadhalpun
wrote:
> On 12.12.2015 10:50, Hendrik Leppkes wrote:
>> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
>> wrote:
>>> On 12.12.2015 01:46, Philip Langdale wrote:
On 2015-12-12 00:03, Andreas Cadhalpun wrote:
> On 11.12.2015 09:41, C
On 12.12.2015 10:50, Hendrik Leppkes wrote:
> On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
> wrote:
>> On 12.12.2015 01:46, Philip Langdale wrote:
>>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
> My point is that so far several people
On Sat, Dec 12, 2015 at 10:39 AM, Andreas Cadhalpun
wrote:
> On 12.12.2015 01:46, Philip Langdale wrote:
>> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
My point is that so far several people have said that if nvenc
is a system library th
On 12.12.2015 10:37, Matt Oliver wrote:
>>
>> When running ffmpeg on Debian (main), where these Nvidia blobs
>> are not present and not needed (because nouveau is used as driver),
>> no component of the operating system, major or not,
>> has been distributed with Nvidia's blobs, so the system libra
On 12.12.2015 01:46, Philip Langdale wrote:
> On 2015-12-12 00:03, Andreas Cadhalpun wrote:
>> On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
>>> My point is that so far several people have said that if nvenc
>>> is a system library there is no issue (and I fully agree). I
>>> didn't see a mail (and
>
> When running ffmpeg on Debian (main), where these Nvidia blobs
> are not present and not needed (because nouveau is used as driver),
> no component of the operating system, major or not,
> has been distributed with Nvidia's blobs, so the system library
> exception does not apply.
>
> I'm not su
On 2015-12-12 00:03, Andreas Cadhalpun wrote:
On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
Well, the problem is that the answer may depend on the system.
If Nvidia offers Graphics Driver for download on its ftp server
for multipl
On 11.12.2015 09:41, Carl Eugen Hoyos wrote:
> On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
>> Well, the problem is that the answer may depend on the system.
>
> If Nvidia offers Graphics Driver for download on its ftp server
> for multiple operating systems, they are either sy
On Friday 11 December 2015 12:16:48 am Andreas Cadhalpun wrote:
> On 11.12.2015 00:03, Carl Eugen Hoyos wrote:
> > On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
> >> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
> >>
> >> die_license_disabled nonfree libaacplus
> >> die
On 2015-12-08 02:53, 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 NVENC SDK
On Fri, Dec 11, 2015 at 12:03 AM, Carl Eugen Hoyos wrote:
> On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
>> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>>
>> die_license_disabled nonfree libaacplus
>> die_license_disabled nonfree libfaac
>> -die_license_disabled non
On 11.12.2015 00:03, Carl Eugen Hoyos wrote:
> On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
>> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>>
>> die_license_disabled nonfree libaacplus
>> die_license_disabled nonfree libfaac
>> -die_license_disabled nonfree nvenc
>
On Monday 07 December 2015 07:53:31 pm Timo Rothenpieler wrote:
> @@ -4807,7 +4807,6 @@ die_license_disabled gpl x11grab
>
> die_license_disabled nonfree libaacplus
> die_license_disabled nonfree libfaac
> -die_license_disabled nonfree nvenc
Sorry, but this makes absolutely no sense imo:
I asked
31 matches
Mail list logo
