[FFmpeg-devel] Politics

[Paul B Mahol]

On Tue, Dec 14, 2021 at 5:00 AM Soft Works <softworkz at hotmail.com> wrote:

>
>
> > -----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.


This is really irrelevant, please stop insisting on hacks like subtitle_pts.


>
>
> 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
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>