On Wed, Dec 15, 2021 at 2:34 PM Soft Works <softwo...@hotmail.com> wrote:
> > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@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 <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. > > 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-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".
