Hello everyone!
(no meaning attached to which mail I respond to)
While it reads less bad today than it did yesterday night, please try to keep
the things written in the code of conduct in mind, assume best intentions etc.,
this thread didn't quite live up to it IMO.
It's possible to state even st
On Mon, May 13, 2019 at 10:53 PM Carl Eugen Hoyos wrote:
>
> > Release branches provide a guarantee of API, ABI and feature
> > stability.
>
> And we sadly did not always hold that guarantee=-(
Mistakes have been made. We shall strive to be better in the future,
and not use them as an excuse to p
Am Mo., 13. Mai 2019 um 22:46 Uhr schrieb Hendrik Leppkes :
>
> On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote:
> >
> > Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
> > >
> > > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James
On 5/13/2019 5:36 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
>>
>> On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
>>> Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019
On Mon, May 13, 2019 at 10:37 PM Carl Eugen Hoyos wrote:
>
> Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
> >
> > On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
> > >>
> > >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> > >
Am Mo., 13. Mai 2019 um 22:32 Uhr schrieb James Almer :
>
> On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> > Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
> >>
> >> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> >>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
> > 1) S
On 5/13/2019 5:23 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
>>
>> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
>>> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
On Sun, 28 Apr 2019, Marton Balint wrote:
> Hi All,
>
Am Mo., 13. Mai 2019 um 22:18 Uhr schrieb James Almer :
>
> On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> > Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
> >>
> >> On Sun, 28 Apr 2019, Marton Balint wrote:
> >>
> >>> Hi All,
> >>>
> >>> There has been discussion on the mailing list se
On 5/13/2019 5:13 PM, Carl Eugen Hoyos wrote:
> Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
>>
>> On Sun, 28 Apr 2019, Marton Balint wrote:
>>
>>> Hi All,
>>>
>>> There has been discussion on the mailing list several times about the
>>> inclusion of support for closed source component
Am Mo., 13. Mai 2019 um 22:10 Uhr schrieb Marton Balint :
>
> On Sun, 28 Apr 2019, Marton Balint wrote:
>
> > Hi All,
> >
> > There has been discussion on the mailing list several times about the
> > inclusion of support for closed source components (codecs, formats,
> > filters, etc) in the main f
On Sun, 28 Apr 2019, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general consens
On Sun, 28 Apr 2019, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general consens
On Sun, Apr 28, 2019 at 11:02 PM Marton Balint wrote:
>
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened wit
On 28/04/2019 21:02, Marton Balint wrote:
> 1) Should libNDI support be removed from the ffmpeg codebase?
Yes.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abov
On Sun, 28 Apr 2019 22:02:11 +0200 (CEST)
Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: Monday, April 29, 2019 4:02 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [DECISION] Project policy on closed source
> components
>
> Hi All,
>
> Th
On 03.05.2019, at 20:16, Michael Niedermayer wrote:
> On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote:
>> Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick
>> :
>
>> And finally: What do you suggest to "punish the violator"?
>
> while this question wasnt directed at
On Mon, Apr 29, 2019 at 4:02 AM Marton Balint wrote:
>
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened with
> 在 2019年5月4日,上午9:32,Peter Ross 写道:
>
>> On Fri, May 03, 2019 at 10:43:36AM -0700, Baptiste Coudurier wrote:
>>
>>> On May 3, 2019, at 1:15 AM, Paul B Mahol wrote:
>>>
>>> On 4/28/19, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times ab
On Fri, May 03, 2019 at 10:43:36AM -0700, Baptiste Coudurier wrote:
>
> > On May 3, 2019, at 1:15 AM, Paul B Mahol wrote:
> >
> > On 4/28/19, Marton Balint wrote:
> >> Hi All,
> >>
> >> There has been discussion on the mailing list several times about the
> >> inclusion of support for closed s
On Fri, May 03, 2019 at 11:08:35AM +0200, Carl Eugen Hoyos wrote:
> Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick
> :
>
> > In this case NDI took prompt action and removed the said binaries from
> > their website immediately.
>
> This is not true, please stop spreading this wrong cl
> On May 3, 2019, at 1:15 AM, Paul B Mahol wrote:
>
> On 4/28/19, Marton Balint wrote:
>> Hi All,
>>
>> There has been discussion on the mailing list several times about the
>> inclusion of support for closed source components (codecs, formats,
>> filters, etc) in the main ffmpeg codebase.
>>
On Fri, 3 May 2019, at 07:27, Jeyapal, Karthick wrote:
> Open source violation by NDI is a serious issue that needs to be
> addressed. But removing the libndi plugin from the ffmpeg repository
> will not address the issue of violation. A willful violator can still
You are confusing 2 things:
-
On Fri, 3 May 2019 at 15:24, Kieran Kunhya wrote:
> >
> >
> > Kieran,
> >
> > Can you point to evidence on the same? An active legal threat to "a
> > developer writing an open source implementation of NDI"?
> >
> > With that in place, it wouldn't be ignored as a material fact, would it?
> >
>
> h
>
>
> Kieran,
>
> Can you point to evidence on the same? An active legal threat to "a
> developer writing an open source implementation of NDI"?
>
> With that in place, it wouldn't be ignored as a material fact, would it?
>
https://trac.ffmpeg.org/ticket/7589
Discussed in there. A few people in t
Am Fr., 3. Mai 2019 um 07:27 Uhr schrieb Jeyapal, Karthick
:
> In this case NDI took prompt action and removed the said binaries from their
> website immediately.
This is not true, please stop spreading this wrong claim.
> A similar violation was done by Amazon some time back
> (https://trac.f
On 5/3/19, Gyan wrote:
>
>
> On 29-04-2019 01:32 AM, Marton Balint wrote:
>> So here is a call to the voting committee [1] to decide on the
>> following two questions:
>>
>> 1) Should libNDI support be removed from the ffmpeg codebase?
>
> No.
>
Yes.
> Gyan
>
On 29-04-2019 01:32 AM, Marton Balint wrote:
So here is a call to the voting committee [1] to decide on the
following two questions:
1) Should libNDI support be removed from the ffmpeg codebase?
No.
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel
On Fri, May 3, 2019, 10:22 Kieran Kunhya wrote:
> On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote:
>
> >
> > On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
> >
> > > (In this case, NDI plugin is already open source).
>
>
> This is untrue.
>
> Furthermore, I am amazed you are all ignori
On 4/28/19, Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without general consensus,
On Fri, 3 May 2019, 06:27 Jeyapal, Karthick, wrote:
>
> On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
>
> > (In this case, NDI plugin is already open source).
This is untrue.
Furthermore, I am amazed you are all ignoring the fact this is an Open
Source hostile company, actively sending
On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened with
Am Do., 2. Mai 2019 um 12:30 Uhr schrieb Timo Rothenpieler
:
>
> On 28/04/2019 22:02, Marton Balint wrote:
> > 1) Should libNDI support be removed from the ffmpeg codebase?
>
> No
What do you suggest instead?
Carl Eugen
___
ffmpeg-devel mailing list
ff
On 28/04/2019 22:02, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general consensus
Marton Balint (12019-04-28):
> 1) Should libNDI support be removed from the ffmpeg codebase?
Yes.
> 2) Should patches using closed source libraries which are not considered
> "System Libraries" according to the GPL be rejected?
Yes to that too, even though the vote was withdrawn pending
clarific
On 4/29/2019 1:34 AM, Gyan wrote:
>
>
> On 29-04-2019 05:37 AM, Marton Balint wrote:
>>
>>
>> On Sun, 28 Apr 2019, Marton Balint wrote:
>>
>>> Hi All,
>>>
>>> There has been discussion on the mailing list several times about the
>>> inclusion of support for closed source components (codecs, forma
Hi,
On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened
On Mon, Apr 29, 2019 at 8:35 PM Marton Balint wrote:
> We can't really change this for the better unless there is a somewhat
> "recognized" authority which has the power to make decisions, rules, and
> enforce them.
>
> I hoped that this can be the voting comitte.
The voting commitee is pretty mu
2019-04-29 20:34 GMT+02:00, Marton Balint :
> Voting is important, because people typically accept
> majority decisions even if they don't agree with them.
Sounds like an interesting argument.
> I believe that this is why several people including
> me expressed that NDI removal should only have
>
Marton Balint (12019-04-29):
> At the moment, it looks to me that FFmpeg is a community without leadership,
> enforced rules and consequences. In fact, I consider this the main reason
> why people consider working in it an unfriendly experience.
>
> We can't really change this for the better unles
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote:
2019-04-29 1:02 GMT+02:00, Marton Balint :
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote:
2019-04-28 22:02 GMT+02:00, Marton Balint :
1) Should libNDI support be removed from the ffmpeg codebase?
This sounds to me as if you know of an alternat
2019-04-29 1:02 GMT+02:00, Marton Balint :
>
> On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote:
>
>> 2019-04-28 22:02 GMT+02:00, Marton Balint :
>>
>>> 1) Should libNDI support be removed from the ffmpeg codebase?
>>
>> This sounds to me as if you know of an alternative to not endorsing
>> a company th
On 4/29/2019 4:23 AM, Reimar Döffinger wrote:
> On 28.04.2019, at 22:02, Marton Balint wrote:
>
>> Hi All,
>>
>> There has been discussion on the mailing list several times about the
>> inclusion of support for closed source components (codecs, formats, filters,
>> etc) in the main ffmpeg codeb
On 28.04.2019, at 22:02, Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats, filters,
> etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without
On 29-04-2019 05:37 AM, Marton Balint wrote:
On Sun, 28 Apr 2019, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the r
Hi,
On Sun, Apr 28, 2019 at 8:14 PM Marton Balint wrote:
> On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
> > On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote:
> >> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
> >> >>> 2) Should patches using closed source libraries which are not
>
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote:
>> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
>>> 2) Should patches using closed source libraries which are not considered
>>> "System Libraries" according to the GPL be rejected?
>>
On Sun, 28 Apr 2019, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general consen
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote:
2019-04-28 22:02 GMT+02:00, Marton Balint :
1) Should libNDI support be removed from the ffmpeg codebase?
This sounds to me as if you know of an alternative to not endorsing
a company that profits from FFmpeg while at the same time
violating the
2019-04-28 22:02 GMT+02:00, Marton Balint :
> 1) Should libNDI support be removed from the ffmpeg codebase?
This sounds to me as if you know of an alternative to not endorsing
a company that profits from FFmpeg while at the same time
violating the copyright of the FFmpeg developers?
What could th
On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote:
> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
> >>> 2) Should patches using closed source libraries which are not considered
> >>> "System Libraries" according to the GPL be rejected?
> >>
> >> You mean "major components"?
> >> (at no
On Sun, 28 Apr 2019, Marton Balint wrote:
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
2) Should patches using closed source libraries which are not considered
"System Libraries" according to the GPL be rejected?
You mean "major c
On Sun, 28 Apr 2019, Mark Thompson wrote:
On 28/04/2019 21:02, Marton Balint wrote:
... closed source libraries which are not considered "System Libraries"
according to the GPL ...
Please can you define this in a precise way which does not rely upon
interpreting the GPL? There are certai
2019-04-28 23:34 GMT+02:00, Marton Balint :
>
> On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote:
>
>> 2019-04-28 22:02 GMT+02:00, Marton Balint :
>>> 2) Should patches using closed source libraries which are not
>>> considered "System Libraries" according to the GPL be rejected?
>>
>> Do I understand c
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote:
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
2) Should patches using closed source libraries which are not considered
"System Libraries" according to the GPL be rejected?
You mean "major components"?
(at no point does the GPLv2 mentio
On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote:
2019-04-28 22:02 GMT+02:00, Marton Balint :
2) Should patches using closed source libraries which are not
considered "System Libraries" according to the GPL be rejected?
Do I understand correctly that this question is equivalent to
requesting the
2019-04-28 23:29 GMT+02:00, Jean-Baptiste Kempf :
> On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote:
>> 2019-04-28 22:02 GMT+02:00, Marton Balint :
>> > 2) Should patches using closed source libraries which are not
>> > considered "System Libraries" according to the GPL be rejected?
>>
>> Do
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote:
> 2) Should patches using closed source libraries which are not considered
> "System Libraries" according to the GPL be rejected?
You mean "major components"?
(at no point does the GPLv2 mention "System Libraries".
--
Jean-Baptiste Kempf -
On 28/04/2019 21:02, Marton Balint wrote:
> ... closed source libraries which are not considered "System Libraries"
> according to the GPL ...
Please can you define this in a precise way which does not rely upon
interpreting the GPL? There are certainly differing opinions about exactly
what it
On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote:
> 2019-04-28 22:02 GMT+02:00, Marton Balint :
> > 2) Should patches using closed source libraries which are not
> > considered "System Libraries" according to the GPL be rejected?
>
> Do I understand correctly that this question is equivalent
>
> [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html
There are numerous inactive people in the voting committee, some for years.
Why are they arbitrarily allowed to vote on this?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-deve
On Sun, 28 Apr 2019, James Almer wrote:
On 4/28/2019 5:02 PM, Marton Balint wrote:
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of
2019-04-28 22:02 GMT+02:00, Marton Balint :
> 2) Should patches using closed source libraries which are not
> considered "System Libraries" according to the GPL be rejected?
Do I understand correctly that this question is equivalent to
requesting the removal of the decklink wrapper?
Carl Eugen
__
On 4/28/2019 5:02 PM, Marton Balint wrote:
> Hi All,
>
> There has been discussion on the mailing list several times about the
> inclusion of support for closed source components (codecs, formats,
> filters, etc) in the main ffmpeg codebase.
>
> Also the removal of libNDI happened without general
Hi All,
There has been discussion on the mailing list several times about the
inclusion of support for closed source components (codecs, formats,
filters, etc) in the main ffmpeg codebase.
Also the removal of libNDI happened without general consensus, so a vote
is necessary to justify the re
65 matches
Mail list logo