Message ID | 20221114091309.15755-2-anton@khirnov.net |
---|---|
State | Accepted |
Commit | c0c492dd47c76c4ef45ddc565f34b451981b2088 |
Headers | show |
Series | [FFmpeg-devel,1/4] doc/developer.texi: improve the introductory text | expand |
Context | Check | Description |
---|---|---|
andriy/make_x86 | success | Make finished |
andriy/make_fate_x86 | success | Make fate finished |
> -----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
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. +@item +FFmpeg developers include leading experts in the field who can find bugs or +design flaws in your code. +@item +By supporting the project you find useful you ensure it continues to be +maintained and developed. +@end itemize For more detailed legal information about the use of FFmpeg in external programs read the @file{LICENSE} file in the source tree and