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

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Monday, November 14, 2022 11:06 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at 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