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