On Tue, Dec 14, 2021 at 5:00 AM Soft Works <softwo...@hotmail.com> wrote:
> > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@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. > > > 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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
