[FFmpeg-devel] Politics

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Daniel
> Cantarín
> Sent: Tuesday, December 14, 2021 4:05 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] Politics
> 
> 
>  >
>  > As mentioned already, I have an offer to make. It might not be exactly
>  > what you want, but it's all you can get.
>  >
>  > Everybody will need to make up his mind and decide whether the benefits
>  > will outweigh the drawback from one's own point of view - or not.
>  >
> 
> 
> I don't feel I have a voice here in the same way other devs do: I don't
> even have a week here, it would be a joke speaking as if I were at the
> same level that people with 10+ years of experience in the community.
> So let me be clear: I'm not at the same level, my words can't be valued
> the same as other people here.
> 
> Also, I'm very doubtful of how to express myself here, because when I
> naively tried to intervene in the patch debate I later felt all I achieved
> was to ignite old grudges between very tired people that was dealing
> with this patch for months. For moments, I feel I should just shut my
> mouth and let the thing be, without kinda embarrasing myself and
> unintendly triggering others. It's very awkward and sad.
> 
> Yet, I believe I can note some common sense and experience points
> from my perspective, even without being sure about its value. My
> hope is to note something perhaps other people does not realize.
> I've done it before, but I see other devs involved in this thread, and
> so I believe doing it again is in order. Specially if this thread is the
> final frontier between accepting or rejecting the patch. So, it's just a
> testimony from my experience, to be noted in the thread.
> 
> I absolutelly love the use cases implemented by this patch. It's been
> years since there's people wanting this, me included, and specially
> the live streaming people will benefit a lot from it.
> 
> Live streaming has problems that file handling does not. Timings are a
> curse, you can't probe just like that so your setup needs always extra
> parameters and filters, there's no start and finish in the same sense
> as it happens with files, there's the sparseness problem (which is a big
> deal for filters), and so on. Yet, so often people evaluate live streaming
> problems with a file mindset, that most of the time this problems are
> understood as some kind of "border cases" with no merit for "a hack";
> where that hack is usually "something I can do right now without
> breaking anything else".
> 
> All of this stuff can be done using other tools when it comes to files.
> But real time? Live? Forget it: that's another deal, and this patch does
> the job. And not only that: I've tested it, and it works amazingly well.
> It's much better than what I ever had expected to find. I was looking
> for useful bits and pieces of code, ideas even, that I could use to
> solve live streaming problems. What I've found feels the same as
> when any of us found ffmpeg for the first time when looking for a
> tool: "this is amazing, it does everything!"
> 
> Of course, this does not means an even more deep refactor isn't
> actually needed. However, we live streaming people keep waiting for
> that use cases for years (there can be found discussions a decade
> old), while the "proper way to do it" never happens.
> 
> That sounds rude to the people involved. But my intention is not to be
> rude, but to express how it feels to be on the other side of the
> development cycle. I said one day "I'll do it myself", then I found the
> thing beyond me: I don't have the time to do all that work, to learn all
> that knowledge and articulate it in a way other people with much
> more knowledge than I have could accept. It's a lot. And I believe I
> can speak for lots of us when I say to have keeped our code private
> knowing it will never be accepted mainline as it is, because it does
> not refactors ffmpeg or libavfilter and just solves something quickly.
> 
> softworkz is now clearly tired of this patchset, and so are the devs
> discussing it with him. When I didn't knew that this thing had been
> going on for six months, I was hoping to be able to somehow get in
> the middle of the debate and try to unblock it. I was hoping to help
> coding here and there, testing this and that, comparing ideas...
> I was actually beginning to analize the code, in order to see if I was
> able to remove the controversial subtitle_pts property. I realize now
> I was sadly too late to the party.
> 
> Yet, here we are, with code that actually do the job, and even
> performs pretty well.
> 
> With all this in mind, here are my feelings about this:
> 
>    - I could not care less about subtitle_pts. I know it's questionable,
>      but screw it: its also questionable to wait for years with live
>      streams problems as some kind of second class citizens. This
>      property and all around this patchset (the good and the bad) are
>      but accidents of the project's history, and those will keep on
>      happening no matter what. We CAN fix subtitle_pts later,
>      without having to wait forever for the concensual
>      implementation in order to have the use cases implemented.
>      That's not a crime: not against "good programing", and neither
>      against ffmpeg.
> 
>    - I don't think subtitle_pts is the real problem here. I think there
>      are grudges between devs, and things going on I don't fully
>      understand. Sadly, as I have no more time to participate in
>      this development (given that everybody's tired, and a call for
>      a vote seems imminent), I can't also read the 6 months of
>      debates to gain a better understanding before expressing
>      an opinion. Sorry devs, you deserve better than this
>      ignorance of mine. Perhaps somebody could make a list of
>      relevant links to discussions before the vote?
> 
>    - I'm more worried about not breaking anything. I saw some
>      notes from Mr. Niedermayer, and could reproduce myself some
>      problems. However, softworkz seems to be willing to fix that
>      kind of issues, so doesn't seem to be a big deal. I see he
>      actually posted a new version of his patchset minutes ago,
>      so that's great. The point is, I would find this kind of things
>      actually blockers, and not subtitle_pts.
> 
>    - If this patchset get rejected, I believe a proper consensual
>      design is in order. Consensual between the relevant devs,
>      of course. But so far, I don't see it linked in the debates.
>      Most likely it is somewhere and I just didn't saw it. But my
>      point is that rejecting this kind of works should be done
>      with a proper explanation, and the acceptable design
>      should be part of that explanation. With that guidelines,
>      perhaps others like me could progressively implement the
>      thing. But, to be honest, rejecting this without a clear and
>      consise designs counterpart (and not only sparse ideas, as
>      we all have some of those), would be frankly rude to both
>      the people who did the job and the people who wants the
>      use cases: because this works, and it's right here.
> 
>    - I would also note that perhaps tiredness would be solved
>      by resting, and not either by an ultimatum or a complete
>      dismissal of the propossal. I would be very happy to
>      collaborate (as I could, which I fear may not be much) if
>      you people happen to just find the energy to take a look
>      at the thing again without so much... err... "painful
>      exchanges" (I speak spanish, sorry, my english is limited).
>      Finally having this use cases should be something to
>      celebrate, and not something depressing. I know, this is
>      some kinda hippie thinking of mine. But I feel it's worth
>      the note anyways.
> 
> 
> Just my 2 cents.
> Thanks,
> Daniel.

Hi Daniel,

thanks for your comments. I basically think that others should
respond to this, but I'd like to add a few remarks.

Once for the facts: the subtitle_pts field in AVFrame exists since
V5 of my patchset, which I have submitted on 2021-09-12.
This has been 3 months ago. Nobody had objected its existence
until only 2 or 3 weeks ago. 

I really hate to read such things like "we had always told you
right from the beginning...", because those are fairy tales.

I had submitted the first version of the patchset on 2021-08-19,
almost four months ago.
For three and a half months, I had done everything that was
requested without exception and without rejection.

And now - after such a long time, others are coming and asking
me to do changes that would set me back for many weeks,
and (as I said a hundred times) wouldn't allow to achieve the
same functionality that I already have.

I do not think that this is acceptable behaviour and even less
acceptable when combined with untrue statements like "we have 
always told you to do...".
What I was told in fact was that I should change fundamental 
things only AFTER I had said that I'm almost done.

Those are the unfortunate facts. Another fact is that 
this whole interaction is drawing away too much time and
attention. That's why my motivation is not to put up an 
ultimatum, but rather my personal need to protect myself
from potentially wasting even more time here.

I hope this makes my position a bít better understandable,
softworkz