On Fri, Mar 8, 2024 at 6:01 PM Kieran Kunhya wrote:
> On Fri, 8 Mar 2024 at 16:50, Nicolas George wrote:
>
> > Kieran Kunhya (12024-03-08):
> > > New contributors are not interested in your biased history lessons.
> They
> > > want to write code and have a modern, well run project, not a
> >
On Fri, 8 Mar 2024 at 16:50, Nicolas George wrote:
> Kieran Kunhya (12024-03-08):
> > New contributors are not interested in your biased history lessons. They
> > want to write code and have a modern, well run project, not a
> dysfunctional
> > mess.
>
> And we go back to the core question: does
Kieran Kunhya (12024-03-08):
> New contributors are not interested in your biased history lessons. They
> want to write code and have a modern, well run project, not a dysfunctional
> mess.
And we go back to the core question: does the strength of this project
come from paid-for contributors
On Fri, 8 Mar 2024 at 16:41, Nicolas George wrote:
> Kieran Kunhya (12024-03-08):
> > Several recent contributors were in nappies during that piece of ancient
> > history. Do you really need to bring it up incessantly and use it as your
> > prism on every issue you disagree with?
>
> Yes, it is
Kieran Kunhya (12024-03-08):
> Several recent contributors were in nappies during that piece of ancient
> history. Do you really need to bring it up incessantly and use it as your
> prism on every issue you disagree with?
Yes, it is necessary, because the same thing is happening again. “Those
who
Ronald S. Bultje (12024-03-08):
> I hope you realize that is what reconciliation looks like.
No, it is not. It is what a takeover disguised as reconciliation looks
like.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Hi Nicolas,
On Fri, Mar 8, 2024 at 10:46 AM Nicolas George wrote:
> [..] you can see they have in the recent years gained a
> lot of influence in FFmpeg [..]
>
I hope you realize that is what reconciliation looks like. In other words:
this was always the goal - from both "sides". You seem to
On Fri, 8 Mar 2024 at 15:46, Nicolas George wrote:
> Sean McGovern (12024-03-08):
> > It is really mean-spirited to make such comments about a project that is
> no
> > longer in operation. Can't we look forward instead of behind us?
>
> The project libav might be dead, but the people who made it
Sean McGovern (12024-03-08):
> It is really mean-spirited to make such comments about a project that is no
> longer in operation. Can't we look forward instead of behind us?
The project libav might be dead, but the people who made it are not, not
even retired, just look who signed its manifest.
On Fri, Mar 8, 2024, 10:37 Vittorio Giovara
wrote:
> On Fri, Mar 8, 2024 at 4:34 PM Sean McGovern wrote:
>
> > On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote:
> >
> > > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara <
> > > vittorio.giov...@gmail.com>
> > > wrote:
> > >
> > > > On Fri, Mar 8,
On Fri, Mar 8, 2024 at 4:34 PM Sean McGovern wrote:
> On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote:
>
> > On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern
> wrote:
> > >
> > > > On Fri, Mar 8,
On Fri, Mar 8, 2024, 10:31 Paul B Mahol wrote:
> On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> wrote:
>
> > On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote:
> >
> > > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote:
> > >
> > > > Andreas Rheinhardt
On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara
wrote:
> On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote:
>
> > On Fri, Mar 8, 2024, 08:20 Nicolas George wrote:
> >
> > > Andreas Rheinhardt (12024-03-08):
> > > > What maintenance cost and complexity are you referring to? I checked
> > and
>
On Fri, Mar 8, 2024, 10:19 Nicolas George wrote:
> Sean McGovern (12024-03-08):
> > Everybody can we *please* keep the responses civil/professional on the
> ML.
>
> Civil, certainly, provided others are civil to me.
>
> Professional, not a chance. This is Libre Software, not a job.
>
> --
>
On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern wrote:
> On Fri, Mar 8, 2024, 08:20 Nicolas George wrote:
>
> > Andreas Rheinhardt (12024-03-08):
> > > What maintenance cost and complexity are you referring to? I checked
> and
> > > could not find a single commit where one had to fix an
Sean McGovern (12024-03-08):
> Everybody can we *please* keep the responses civil/professional on the ML.
Civil, certainly, provided others are civil to me.
Professional, not a chance. This is Libre Software, not a job.
--
Nicolas George
___
On Fri, Mar 8, 2024, 08:20 Nicolas George wrote:
> Andreas Rheinhardt (12024-03-08):
> > What maintenance cost and complexity are you referring to? I checked and
> > could not find a single commit where one had to fix an ff_get_buffer()
> > to ff_thread_get_buffer() because it has been forgotten
On Fri, Mar 8, 2024 at 12:18 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> >>
> >> -1: This adds avoidable runtime checks.
> >
> > What checks and why is that a problem?
> >
> It adds a runtime check to every call to ff_get_buffer() by every
>
On Fri, Mar 8, 2024 at 2:20 PM Nicolas George wrote:
> Andreas Rheinhardt (12024-03-08):
> > What maintenance cost and complexity are you referring to? I checked and
> > could not find a single commit where one had to fix an ff_get_buffer()
> > to ff_thread_get_buffer() because it has been
Andreas Rheinhardt (12024-03-08):
> What maintenance cost and complexity are you referring to? I checked and
> could not find a single commit where one had to fix an ff_get_buffer()
> to ff_thread_get_buffer() because it has been forgotten when the decoder
> has been declared to support frame
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-03-08 11:44:12)
>> Anton Khirnov:
>>> Quoting Andreas Rheinhardt (2024-03-08 11:19:59)
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
>> Anton Khirnov:
>>> ff_thread_get_buffer() has exactly the same semantics as
Quoting Andreas Rheinhardt (2024-03-08 11:44:12)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-03-08 11:19:59)
> >> Anton Khirnov:
> >>> Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
> Anton Khirnov:
> > ff_thread_get_buffer() has exactly the same semantics as
> >
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-03-08 11:19:59)
>> Anton Khirnov:
>>> Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
Anton Khirnov:
> ff_thread_get_buffer() has exactly the same semantics as
> ff_get_buffer(), except it is supposed to be used in frame-threaded
Quoting Andreas Rheinhardt (2024-03-08 11:19:59)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
> >> Anton Khirnov:
> >>> ff_thread_get_buffer() has exactly the same semantics as
> >>> ff_get_buffer(), except it is supposed to be used in frame-threaded
> >>> decoders. Since
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
>> Anton Khirnov:
>>> ff_thread_get_buffer() has exactly the same semantics as
>>> ff_get_buffer(), except it is supposed to be used in frame-threaded
>>> decoders. Since the decoder instance knows whether frame threading is in
>>>
Quoting Andreas Rheinhardt (2024-03-08 11:03:18)
> Anton Khirnov:
> > ff_thread_get_buffer() has exactly the same semantics as
> > ff_get_buffer(), except it is supposed to be used in frame-threaded
> > decoders. Since the decoder instance knows whether frame threading is in
> > use, there is no
Anton Khirnov:
> ff_thread_get_buffer() has exactly the same semantics as
> ff_get_buffer(), except it is supposed to be used in frame-threaded
> decoders. Since the decoder instance knows whether frame threading is in
> use, there is no point in forcing decoder implementations to use a
>
ff_thread_get_buffer() has exactly the same semantics as
ff_get_buffer(), except it is supposed to be used in frame-threaded
decoders. Since the decoder instance knows whether frame threading is in
use, there is no point in forcing decoder implementations to use a
different function merely because
28 matches
Mail list logo
