[FFmpeg-devel] Politics

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Paul B
> Mahol
> Sent: Wednesday, December 15, 2021 10:34 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Politics
> 
> 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.

New idea:

I could remove the three fields (subtitle_pts, subtitle_start_time, 
subtitle_end_time) from AVFrame and add it to AVSubtitleArea.

How about that? It would allow the frame to be "clean" at least.

sw