Re: [FFmpeg-devel] Politics

[Paul B Mahol <onemda@gmail.com>]

On Wed, Dec 15, 2021 at 2:34 PM Soft Works <softworkz@hotmail.com> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Paul B
> > Mahol
> > Sent: Wednesday, December 15, 2021 10:34 AM
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Politics
> >
> > On Tue, Dec 14, 2021 at 5:00 AM Soft Works <softworkz@hotmail.com>
> wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Daniel
> > > > Cantarín
> > > > Sent: Tuesday, December 14, 2021 4:05 AM
> > > > To: ffmpeg-devel@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.
>


Yea, much better, But still original issue is not solved.

Also what about subtitle formats negotiation and auto inserting filters
when needed?


>
> sw
>
>
>
> _______________________________________________
> 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".
>
_______________________________________________
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".