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
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
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
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)
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
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
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
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
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
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
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
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,
>
> There has been discussion on the
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
> 在 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
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
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
> 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?
> >
>
>
>
>
> 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
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
>
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
64 matches
Mail list logo
