[FFmpeg-devel,2/4] doc/developer.texi: extend the argument for submitting patches

Stop talking about commercial programs, since this applies to any
downstream user.
---
 doc/developer.texi | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 10:13 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> argument for submitting patches
> 
> Stop talking about commercial programs, since this applies to any
> downstream user.
> ---
>  doc/developer.texi | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5cf3b19ee0..2f0d2b7daa 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -24,11 +24,21 @@ generated from the headers
>  the examples under @file{doc/examples}
>  @end itemize
> 
> -You can use the FFmpeg libraries in your commercial program, but you
> -are encouraged to @emph{publish any patch you make}. In this case
> the
> -best way to proceed is to send your patches to the ffmpeg-devel
> -mailing list following the guidelines illustrated in the remainder
> of
> -this document.
> +If you modify FFmpeg code for your own use case, you are highly
> encouraged to
> +@emph{submit your changes back to us}, using this document as a
> guide. There are
> +both pragmatic and ideological reasons to do so:
> +@itemize @bullet
> +@item
> +Maintaining external changes to keep up with upstream development is
> +time-consuming and error-prone. With your code in the main tree, it
> will be
> +maintained by FFmpeg developers.

You should mention that sometimes it's not really worth to take the effort,
because waiting for reviews and permanent rebasing and re-submitting,
explaining, defending, getting insulted or ignored and whatsoever,
might end up taking much more time than just to keep and maintain your 
changes privately. Eventually you might regret that you have even
started going that way.

Regards,
softworkz

Quoting Soft Works (2022-11-14 10:35:40)
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Monday, November 14, 2022 10:13 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> > argument for submitting patches
> > 
> > Stop talking about commercial programs, since this applies to any
> > downstream user.
> > ---
> >  doc/developer.texi | 20 +++++++++++++++-----
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> > 
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 5cf3b19ee0..2f0d2b7daa 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -24,11 +24,21 @@ generated from the headers
> >  the examples under @file{doc/examples}
> >  @end itemize
> > 
> > -You can use the FFmpeg libraries in your commercial program, but you
> > -are encouraged to @emph{publish any patch you make}. In this case
> > the
> > -best way to proceed is to send your patches to the ffmpeg-devel
> > -mailing list following the guidelines illustrated in the remainder
> > of
> > -this document.
> > +If you modify FFmpeg code for your own use case, you are highly
> > encouraged to
> > +@emph{submit your changes back to us}, using this document as a
> > guide. There are
> > +both pragmatic and ideological reasons to do so:
> > +@itemize @bullet
> > +@item
> > +Maintaining external changes to keep up with upstream development is
> > +time-consuming and error-prone. With your code in the main tree, it
> > will be
> > +maintained by FFmpeg developers.
> 
> You should mention that sometimes it's not really worth to take the effort,
> because waiting for reviews and permanent rebasing and re-submitting,
> explaining, defending, getting insulted or ignored and whatsoever,
> might end up taking much more time than just to keep and maintain your 
> changes privately. Eventually you might regret that you have even
> started going that way.

Sorry, but you problems are entirely self-inflicted. You have been told
what changes need to happen right from the beginning, repeatedly, and by
several developers independently. Instead of implementing them you chose
to compose ever-more-elaborate explanations and justifications that, as
far as I can tell, boil down to "doing things properly is too much
work". Seems to me that actually doing this work would take less time
than you have already spent arguing.

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 10:53 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 10:35:40)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Monday, November 14, 2022 10:13 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the
> > > argument for submitting patches
> > >
> > > Stop talking about commercial programs, since this applies to any
> > > downstream user.
> > > ---
> > >  doc/developer.texi | 20 +++++++++++++++-----
> > >  1 file changed, 15 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 5cf3b19ee0..2f0d2b7daa 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -24,11 +24,21 @@ generated from the headers
> > >  the examples under @file{doc/examples}
> > >  @end itemize
> > >
> > > -You can use the FFmpeg libraries in your commercial program, but
> you
> > > -are encouraged to @emph{publish any patch you make}. In this
> case
> > > the
> > > -best way to proceed is to send your patches to the ffmpeg-devel
> > > -mailing list following the guidelines illustrated in the
> remainder
> > > of
> > > -this document.
> > > +If you modify FFmpeg code for your own use case, you are highly
> > > encouraged to
> > > +@emph{submit your changes back to us}, using this document as a
> > > guide. There are
> > > +both pragmatic and ideological reasons to do so:
> > > +@itemize @bullet
> > > +@item
> > > +Maintaining external changes to keep up with upstream
> development is
> > > +time-consuming and error-prone. With your code in the main tree,
> it
> > > will be
> > > +maintained by FFmpeg developers.
> >
> > You should mention that sometimes it's not really worth to take the
> effort,
> > because waiting for reviews and permanent rebasing and re-
> submitting,
> > explaining, defending, getting insulted or ignored and whatsoever,
> > might end up taking much more time than just to keep and maintain
> your
> > changes privately. Eventually you might regret that you have even
> > started going that way.
> 
> Sorry, but you problems are entirely self-inflicted. You have been
> told
> what changes need to happen right from the beginning, repeatedly, and
> by
> several developers independently. 

And those are completed and settled, like I had state multiple times.
It's ready for review for months already.

softworkz

Quoting Soft Works (2022-11-14 11:46:49)
> > Sorry, but you problems are entirely self-inflicted. You have been
> > told what changes need to happen right from the beginning,
> > repeatedly, and by several developers independently.
> 
> And those are completed and settled, like I had state multiple times.
> It's ready for review for months already.

Your stating something does not make it true, no matter how many times
you do it.

My objections were not addressed.

In your last resend, Hendrik yet again raised the start_pts question. As
far as I can tell, your explanation for why it's supposedly needed did
not convince ANYONE.

Some random quotes from IRC:
2022-09-01 00:25:21     @Lynne  elenril: I never retracted my insistence on using the native frame fields for subtitles
2022-09-01 00:25:27     @Lynne  not sure how softworks got that idea

2022-09-01 02:23:50     @BBB    subtitle.start_pts is really the emblem of the whole problem, I feel
2022-09-01 02:24:04     @BBB    there's many issues. but that one demonstrates it

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 12:08 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 11:46:49)
> > > Sorry, but you problems are entirely self-inflicted. You have
> been
> > > told what changes need to happen right from the beginning,
> > > repeatedly, and by several developers independently.
> >
> > And those are completed and settled, like I had state multiple
> times.
> > It's ready for review for months already.
> 
> Your stating something does not make it true, no matter how many
> times
> you do it.
> 
> My objections were not addressed.
> 
> In your last resend, Hendrik yet again raised the start_pts question.
> As
> far as I can tell, your explanation for why it's supposedly needed
> did
> not convince ANYONE.

What means "as far as I can tell" here? Do you have something to 
say about it, then please do?

I cannot talk and respond to any "ghost" statements which I'm not 
aware of.

And regarding the IRC snippet: Well, interesting, but I can neither
know not respond to anything I'm not aware of.


I had taken the effort to explain the reasons this in this article:

https://github.com/softworkz/SubtitleFilteringDemos/issues/1

and Hendrik didn't respond. So whom should I talk to, in order 
to find a solution, especially, considering the fact, that
nobody has really taken the effort to ACTUALLY understand what
the problem is?


Thanks,
softworkz

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 12:08 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 11:46:49)
> > > Sorry, but you problems are entirely self-inflicted. You have
> been
> > > told what changes need to happen right from the beginning,
> > > repeatedly, and by several developers independently.
> >
> > And those are completed and settled, like I had state multiple
> times.
> > It's ready for review for months already.

[...]

> 
> Some random quotes from IRC:
> 2022-09-01 00:25:21     @Lynne  elenril: I never retracted my
> insistence on using the native frame fields for subtitles
> 2022-09-01 00:25:27     @Lynne  not sure how softworks got that idea

I got that "idea" from this discussion:

Jan 14 02:46:02 <Lynne>	can't you really not hide away everything to do with repetition, subtitle pts, and subtitle duration all into the private opqaue field, and give the user what they expect when the frames go out of lavfi?
Jan 14 02:46:55 <softworkz>	worth a thought, but I'm not sure
Jan 14 02:49:32 <softworkz>	I think it's better to make it more transparent. the heartbeat mechanism has been a hidden thing and that's why it wasn't an ideal solution
Jan 14 02:50:10 <softworkz>	when you already need to understand when and why you need to insert a subfeed filter, then there's no point in hiding the effect imo
Jan 14 02:50:53 <Lynne>	I think that's worth a really good look
Jan 14 02:50:56 <softworkz>	the good thing is, that often none of that is needed at all
Jan 14 02:51:15 <softworkz>	(say sometimes..)
Jan 14 02:52:04 <Lynne>	if you could hide all of that into the opaque field, I'd be happy with the patch

This IS a retraction from the "insistence on using the native frame 
fields for subtitles."

(because the actual subtitle timings would be in that opaque field)

Regards,
softworkz

Anton Khirnov (12022-11-14):
> In your last resend, Hendrik yet again raised the start_pts question. As
> far as I can tell, your explanation for why it's supposedly needed did
> not convince ANYONE.

Not only that: this series is completely broken with regard to
negotiation, scheduling and utility filters. Not remotely ready for
review.

Quoting Soft Works (2022-11-14 12:20:00)
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Monday, November 14, 2022 12:08 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> > the argument for submitting patches
> > 
> > Quoting Soft Works (2022-11-14 11:46:49)
> > > > Sorry, but you problems are entirely self-inflicted. You have
> > been
> > > > told what changes need to happen right from the beginning,
> > > > repeatedly, and by several developers independently.
> > >
> > > And those are completed and settled, like I had state multiple
> > times.
> > > It's ready for review for months already.
> > 
> > Your stating something does not make it true, no matter how many
> > times
> > you do it.
> > 
> > My objections were not addressed.
> > 
> > In your last resend, Hendrik yet again raised the start_pts question.
> > As
> > far as I can tell, your explanation for why it's supposedly needed
> > did
> > not convince ANYONE.
> 
> What means "as far as I can tell" here? Do you have something to 
> say about it, then please do?

It means that I am not aware of anyone who changed their stance based on
your arguments, but cannot prove that no such person exists.

> 
> I cannot talk and respond to any "ghost" statements which I'm not 
> aware of.
> 
> And regarding the IRC snippet: Well, interesting, but I can neither
> know not respond to anything I'm not aware of.
> 
> 
> I had taken the effort to explain the reasons this in this article:
> 
> https://github.com/softworkz/SubtitleFilteringDemos/issues/1
> 
> and Hendrik didn't respond. So whom should I talk to, in order 
> to find a solution, especially, considering the fact, that
> nobody has really taken the effort to ACTUALLY understand what
> the problem is?

I did read your document, and my takeaway message from it is "doing it
properly is too hard". As long as that continues to be your position,
you might as well not bother.

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 3:35 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 12:20:00)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Monday, November 14, 2022 12:08 PM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
> extend
> > > the argument for submitting patches
> > >
> > > Quoting Soft Works (2022-11-14 11:46:49)
> > > > > Sorry, but you problems are entirely self-inflicted. You have
> > > been
> > > > > told what changes need to happen right from the beginning,
> > > > > repeatedly, and by several developers independently.
> > > >
> > > > And those are completed and settled, like I had state multiple
> > > times.
> > > > It's ready for review for months already.
> > >
> > > Your stating something does not make it true, no matter how many
> > > times
> > > you do it.
> > >
> > > My objections were not addressed.
> > >
> > > In your last resend, Hendrik yet again raised the start_pts
> question.
> > > As
> > > far as I can tell, your explanation for why it's supposedly
> needed
> > > did
> > > not convince ANYONE.
> >
> > What means "as far as I can tell" here? Do you have something to
> > say about it, then please do?
> 
> It means that I am not aware of anyone who changed their stance based
> on
> your arguments, but cannot prove that no such person exists.

I'm afraid, but everything you are writing is making references to 
others and what they would think or what you are assuming that they
might think.

> I did read your document, and my takeaway message from it is "doing
> it
> properly is too hard". As long as that continues to be your position,
> you might as well not bother.

This is ridiculous, and you know that. Or at least you would know
if you would have really tried to understand the problem.

And that unfortunately applies to some others as well. Nobody is 
willing to go deep enough to the point where it becomes clear
that a "perfect" solution would only be possible by making fundamental
changes to libavfilter, which are complex, risky and something
that would never be accepted from me, even when it would be 
the most excellent solution. I think this is pretty clear to 
everybody here, and trying to present this in a light as if
I would just be too lazy to go for it, is just despicable, 
I'm afraid.

I wish you could stop referring to others potential opinions 
and get yourself as much into the subject as it is required to 
understand the actual problem and talk for yourself.

Because I would happily discuss alternatives 
with you and follow your advice, no matter when it takes 
a little more effort - as long as it will still be possible
to handle all cases like with the current patchset.
But I mean substantial and detailed advice based on an 
understanding of the problems, not the kind of "no, that's
bad, I don't believe you that it couldn't be done like I
think it's gotta be".

I will happily, gladly and friendly work and converse with 
anybody who would be so kind to leave one's peripheral 
spectator position and get down with me to the core 
problem and discuss potential solutions.

Thanks,
softworkz

On 11/14/22, Soft Works <softworkz@hotmail.com> wrote:
>
>
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Anton Khirnov
>> Sent: Monday, November 14, 2022 3:35 PM
>> To: FFmpeg development discussions and patches <ffmpeg-
>> devel@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
>> the argument for submitting patches
>>
>> Quoting Soft Works (2022-11-14 12:20:00)
>> >
>> >
>> > > -----Original Message-----
>> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> > > Anton Khirnov
>> > > Sent: Monday, November 14, 2022 12:08 PM
>> > > To: FFmpeg development discussions and patches <ffmpeg-
>> > > devel@ffmpeg.org>
>> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
>> extend
>> > > the argument for submitting patches
>> > >
>> > > Quoting Soft Works (2022-11-14 11:46:49)
>> > > > > Sorry, but you problems are entirely self-inflicted. You have
>> > > been
>> > > > > told what changes need to happen right from the beginning,
>> > > > > repeatedly, and by several developers independently.
>> > > >
>> > > > And those are completed and settled, like I had state multiple
>> > > times.
>> > > > It's ready for review for months already.
>> > >
>> > > Your stating something does not make it true, no matter how many
>> > > times
>> > > you do it.
>> > >
>> > > My objections were not addressed.
>> > >
>> > > In your last resend, Hendrik yet again raised the start_pts
>> question.
>> > > As
>> > > far as I can tell, your explanation for why it's supposedly
>> needed
>> > > did
>> > > not convince ANYONE.
>> >
>> > What means "as far as I can tell" here? Do you have something to
>> > say about it, then please do?
>>
>> It means that I am not aware of anyone who changed their stance based
>> on
>> your arguments, but cannot prove that no such person exists.
>
> I'm afraid, but everything you are writing is making references to
> others and what they would think or what you are assuming that they
> might think.
>
>> I did read your document, and my takeaway message from it is "doing
>> it
>> properly is too hard". As long as that continues to be your position,
>> you might as well not bother.
>
> This is ridiculous, and you know that. Or at least you would know
> if you would have really tried to understand the problem.
>
> And that unfortunately applies to some others as well. Nobody is
> willing to go deep enough to the point where it becomes clear
> that a "perfect" solution would only be possible by making fundamental
> changes to libavfilter, which are complex, risky and something
> that would never be accepted from me, even when it would be
> the most excellent solution. I think this is pretty clear to
> everybody here, and trying to present this in a light as if
> I would just be too lazy to go for it, is just despicable,
> I'm afraid.
>
> I wish you could stop referring to others potential opinions
> and get yourself as much into the subject as it is required to
> understand the actual problem and talk for yourself.
>
> Because I would happily discuss alternatives
> with you and follow your advice, no matter when it takes
> a little more effort - as long as it will still be possible
> to handle all cases like with the current patchset.
> But I mean substantial and detailed advice based on an
> understanding of the problems, not the kind of "no, that's
> bad, I don't believe you that it couldn't be done like I
> think it's gotta be".
>
> I will happily, gladly and friendly work and converse with
> anybody who would be so kind to leave one's peripheral
> spectator position and get down with me to the core
> problem and discuss potential solutions.

They can not admit they have zero understanding why and how code works
Instead they propose some nonsense that hardly can be implemented.

>
> Thanks,
> softworkz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Monday, November 14, 2022 4:18 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> On 11/14/22, Soft Works <softworkz@hotmail.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Anton Khirnov
> >> Sent: Monday, November 14, 2022 3:35 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> >> the argument for submitting patches
> >>
> >> Quoting Soft Works (2022-11-14 12:20:00)
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >> > > Anton Khirnov
> >> > > Sent: Monday, November 14, 2022 12:08 PM
> >> > > To: FFmpeg development discussions and patches <ffmpeg-
> >> > > devel@ffmpeg.org>
> >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
> >> extend
> >> > > the argument for submitting patches
> >> > >
> >> > > Quoting Soft Works (2022-11-14 11:46:49)
> >> > > > > Sorry, but you problems are entirely self-inflicted. You
> have
> >> > > been
> >> > > > > told what changes need to happen right from the beginning,
> >> > > > > repeatedly, and by several developers independently.
> >> > > >
> >> > > > And those are completed and settled, like I had state
> multiple
> >> > > times.
> >> > > > It's ready for review for months already.
> >> > >
> >> > > Your stating something does not make it true, no matter how
> many
> >> > > times
> >> > > you do it.
> >> > >
> >> > > My objections were not addressed.
> >> > >
> >> > > In your last resend, Hendrik yet again raised the start_pts
> >> question.
> >> > > As
> >> > > far as I can tell, your explanation for why it's supposedly
> >> needed
> >> > > did
> >> > > not convince ANYONE.
> >> >
> >> > What means "as far as I can tell" here? Do you have something to
> >> > say about it, then please do?
> >>
> >> It means that I am not aware of anyone who changed their stance
> based
> >> on
> >> your arguments, but cannot prove that no such person exists.
> >
> > I'm afraid, but everything you are writing is making references to
> > others and what they would think or what you are assuming that they
> > might think.
> >
> >> I did read your document, and my takeaway message from it is
> "doing
> >> it
> >> properly is too hard". As long as that continues to be your
> position,
> >> you might as well not bother.
> >
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> >
> > And that unfortunately applies to some others as well. Nobody is
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making
> fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be
> > the most excellent solution. I think this is pretty clear to
> > everybody here, and trying to present this in a light as if
> > I would just be too lazy to go for it, is just despicable,
> > I'm afraid.
> >
> > I wish you could stop referring to others potential opinions
> > and get yourself as much into the subject as it is required to
> > understand the actual problem and talk for yourself.
> >
> > Because I would happily discuss alternatives
> > with you and follow your advice, no matter when it takes
> > a little more effort - as long as it will still be possible
> > to handle all cases like with the current patchset.
> > But I mean substantial and detailed advice based on an
> > understanding of the problems, not the kind of "no, that's
> > bad, I don't believe you that it couldn't be done like I
> > think it's gotta be".
> >
> > I will happily, gladly and friendly work and converse with
> > anybody who would be so kind to leave one's peripheral
> > spectator position and get down with me to the core
> > problem and discuss potential solutions.
> 
> They can not admit they have zero understanding why and how code
> works
> Instead they propose some nonsense that hardly can be implemented.

I'm not saying that and I have no doubt they could..

sw

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Monday, November 14, 2022 4:18 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> On 11/14/22, Soft Works <softworkz@hotmail.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Anton Khirnov
> >> Sent: Monday, November 14, 2022 3:35 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> >> the argument for submitting patches
> >>
> >> Quoting Soft Works (2022-11-14 12:20:00)
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >> > > Anton Khirnov
> >> > > Sent: Monday, November 14, 2022 12:08 PM
> >> > > To: FFmpeg development discussions and patches <ffmpeg-
> >> > > devel@ffmpeg.org>
> >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
> >> extend
> >> > > the argument for submitting patches
> >> > >
> >> > > Quoting Soft Works (2022-11-14 11:46:49)
> >> > > > > Sorry, but you problems are entirely self-inflicted. You
> have
> >> > > been
> >> > > > > told what changes need to happen right from the beginning,
> >> > > > > repeatedly, and by several developers independently.
> >> > > >
> >> > > > And those are completed and settled, like I had state
> multiple
> >> > > times.
> >> > > > It's ready for review for months already.
> >> > >
> >> > > Your stating something does not make it true, no matter how
> many
> >> > > times
> >> > > you do it.
> >> > >
> >> > > My objections were not addressed.
> >> > >
> >> > > In your last resend, Hendrik yet again raised the start_pts
> >> question.
> >> > > As
> >> > > far as I can tell, your explanation for why it's supposedly
> >> needed
> >> > > did
> >> > > not convince ANYONE.
> >> >
> >> > What means "as far as I can tell" here? Do you have something to
> >> > say about it, then please do?
> >>
> >> It means that I am not aware of anyone who changed their stance
> based
> >> on
> >> your arguments, but cannot prove that no such person exists.
> >
> > I'm afraid, but everything you are writing is making references to
> > others and what they would think or what you are assuming that they
> > might think.
> >
> >> I did read your document, and my takeaway message from it is
> "doing
> >> it
> >> properly is too hard". As long as that continues to be your
> position,
> >> you might as well not bother.
> >
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> >
> > And that unfortunately applies to some others as well. Nobody is
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making
> fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be
> > the most excellent solution. I think this is pretty clear to
> > everybody here, and trying to present this in a light as if
> > I would just be too lazy to go for it, is just despicable,
> > I'm afraid.
> >
> > I wish you could stop referring to others potential opinions
> > and get yourself as much into the subject as it is required to
> > understand the actual problem and talk for yourself.
> >
> > Because I would happily discuss alternatives
> > with you and follow your advice, no matter when it takes
> > a little more effort - as long as it will still be possible
> > to handle all cases like with the current patchset.
> > But I mean substantial and detailed advice based on an
> > understanding of the problems, not the kind of "no, that's
> > bad, I don't believe you that it couldn't be done like I
> > think it's gotta be".
> >
> > I will happily, gladly and friendly work and converse with
> > anybody who would be so kind to leave one's peripheral
> > spectator position and get down with me to the core
> > problem and discuss potential solutions.
> 
> They can not admit they have zero understanding why and how code
> works
> Instead they propose some nonsense that hardly can be implemented.

Nobody has actually proposed anything. I wish somebody had.

"No, not like this, I don't care whether and how it can be 
done otherwise" - is not a proposal.

sw

Quoting Soft Works (2022-11-14 16:13:29)
> > I did read your document, and my takeaway message from it is "doing
> > it
> > properly is too hard". As long as that continues to be your position,
> > you might as well not bother.
> 
> This is ridiculous, and you know that. Or at least you would know
> if you would have really tried to understand the problem.
> 
> And that unfortunately applies to some others as well. Nobody is 
> willing to go deep enough to the point where it becomes clear
> that a "perfect" solution would only be possible by making fundamental
> changes to libavfilter, which are complex, risky and something
> that would never be accepted from me, even when it would be 
> the most excellent solution.

Stop with the drama, please. You are not a persecuted misunderstood
genius. Nobody here has a personal grudge against you. The reason
people, including me, are objecting to your patches is that they are not
fundamental enough. You want to redo the subtitle API in a major way,
but keep it saddled with legacy hacks right from the start. We have
enough of those already to know we don't want any more.

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 5:14 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 16:13:29)
> > > I did read your document, and my takeaway message from it is
> "doing
> > > it
> > > properly is too hard". As long as that continues to be your
> position,
> > > you might as well not bother.
> >
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> >
> > And that unfortunately applies to some others as well. Nobody is
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making
> fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be
> > the most excellent solution.
> 
> Stop with the drama, please. You are not a persecuted misunderstood
> genius. Nobody here has a personal grudge against you. The reason
> people, including me, are objecting to your patches is that they are
> not
> fundamental enough. You want to redo the subtitle API in a major way,
> but keep it saddled with legacy hacks right from the start. We have
> enough of those already to know we don't want any more.

This is so disgusting!

Why can't you just point at those "legacy hacks" and tell how you 
want to have it done instead?

"not fundamental enough"?

Where why and how? 
And why do you keep bullshitting me with such nonsense statements?

What are your points? Which are your objections? Please show the 
code that you think is wrong and say how it should be done instead.

Thanks,
softworkz

Soft Works (12022-11-14):
> What are your points? Which are your objections? Please show the 
> code that you think is wrong and say how it should be done instead.

For the record, I have, multiple times.

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Monday, November 14, 2022 5:40 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Soft Works (12022-11-14):
> > What are your points? Which are your objections? Please show the
> > code that you think is wrong and say how it should be done instead.
> 
> For the record, I have, multiple times.

You’ve been destructive from the very first moment when you realized 
that I was going to do something that you had been planning for a 
long time.
You haven't missed a single occasion to discredit me or my work, 
keeping it vague just like Anton does right now, to keep things at 
a level where credibility weighs - instead than a technical facts.

Ah, wait - there's one occasion where you never jumped on, never 
mentioned, talked about or objected: 

The separate subtitle timing fields. You know exactly why I have
them and why these are needed, but you would rather bite your
tongue than saying it, and so you kept quiet each time when others
were criticizing it.

Now you'll have to say that I'm wrong. 
I'm curious how you'll say it.

PS: I'm sorry that I got in your way, I understood that much 
    later only. It was just that I needed this functionality,
    not that I would have had a choice.

Thanks,
softworkz

Soft Works (12022-11-14):
> You’ve been destructive from the very first moment when you realized 
> that I was going to do something that you had been planning for a 
> long time.

I would have been very happy if you had worked on doing properly, or at
least in a way compatible with doing it properly. This is exactly what
Anton says.

I have not read the rest of your message, since it is built on a lie.

On Mon, Nov 14, 2022 at 05:13:40PM +0100, Anton Khirnov wrote:
> Quoting Soft Works (2022-11-14 16:13:29)
> > > I did read your document, and my takeaway message from it is "doing
> > > it
> > > properly is too hard". As long as that continues to be your position,
> > > you might as well not bother.
> > 
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> > 
> > And that unfortunately applies to some others as well. Nobody is 
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be 
> > the most excellent solution.
> 
> Stop with the drama, please. You are not a persecuted misunderstood
> genius. Nobody here has a personal grudge against you. The reason
> people, including me, are objecting to your patches is that they are not
> fundamental enough. You want to redo the subtitle API in a major way,
> but keep it saddled with legacy hacks right from the start. We have
> enough of those already to know we don't want any more.

Maybe people should take a step back and together discuss with softworks
what changes need to be done.

This thread is a bit odd becasue from reading just it its very clear there
are objections but what exactly needs to be done to move this forward is
not so clear (to me at least).

I think a patch review should result in a clear list of things that need
to be done.
Then these things can be gone through one by one. What can be done what not
where there is consensus, where not and why ...

If a request to a fundamental redesign is there then thats what it is
and maybe noone will do it but IMHO it should be clear so everyone understands
what is requested

As it is, this thread simply makes me sad because its deadlocked, there is
some will and effort on one side and that isnt directed into anything that
goes into the ffmpeg codebase ...

thx

[...]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Monday, November 14, 2022 11:06 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> On Mon, Nov 14, 2022 at 05:13:40PM +0100, Anton Khirnov wrote:
> > Quoting Soft Works (2022-11-14 16:13:29)
> > > > I did read your document, and my takeaway message from it is
> "doing
> > > > it
> > > > properly is too hard". As long as that continues to be your
> position,
> > > > you might as well not bother.
> > >
> > > This is ridiculous, and you know that. Or at least you would know
> > > if you would have really tried to understand the problem.
> > >
> > > And that unfortunately applies to some others as well. Nobody is
> > > willing to go deep enough to the point where it becomes clear
> > > that a "perfect" solution would only be possible by making
> fundamental
> > > changes to libavfilter, which are complex, risky and something
> > > that would never be accepted from me, even when it would be
> > > the most excellent solution.
> >
> > Stop with the drama, please. You are not a persecuted misunderstood
> > genius. Nobody here has a personal grudge against you. The reason
> > people, including me, are objecting to your patches is that they
> are not
> > fundamental enough. You want to redo the subtitle API in a major
> way,
> > but keep it saddled with legacy hacks right from the start. We have
> > enough of those already to know we don't want any more.
> 
> Maybe people should take a step back and together discuss with
> softworks
> what changes need to be done.
> 
> This thread is a bit odd becasue from reading just it its very clear
> there
> are objections but what exactly needs to be done to move this forward
> is
> not so clear (to me at least).

To me neither. Until today.

> I think a patch review should result in a clear list of things that
> need
> to be done.
> Then these things can be gone through one by one. What can be done
> what not
> where there is consensus, where not and why ...
> 
> If a request to a fundamental redesign is there then thats what it is
> and maybe noone will do it but IMHO it should be clear so everyone
> understands
> what is requested
> 
> As it is, this thread simply makes me sad because its deadlocked,
> there is
> some will and effort on one side and that isnt directed into anything
> that
> goes into the ffmpeg codebase ...

I had a friendly chat with Anton on IRC about it. Bottom line is that
he insists that I re-work libavfilter filtering from the ground up to
support non-monotonous pts values in graph processing.

The reason is that the single time_64t field that I want to add as a member
to AVFrame would not be acceptable because it would make timestamp handling
"too messy".

Other objections haven't been made. I asked multiple times whether he
would be serious about this, demanding me to take on a possibly multi-
month work for the reason that having a single additional field in 
AVFrame would be messy, which he confirmed. 

I said it would be a huge amount of work and too much for me to take.
He doubted, saying it can't be that much, I asked what he would expect
me to change and how:

Nov 14 19:08:02 <elenril>	i can't say what to change exactly without actually doing it
Nov 14 19:08:22 <elenril>	i didn't write that code, I only have a very rought idea what it does

Full transcript on request.


I got no more words. Except about the irony that reveals 
when looking at the subject and who wrote it.

Thanks, Michael!

softworkz