On Tue, Jun 3, 2025 at 10:59 AM Nicolas George <geo...@nsup.org> wrote:
> Softworkz has been rude and insulting to me, they have been rude and > insulting to people I respect. > > Are you asking me to suck it up and help them? The way I see it, rudeness has been present on all sides of most of the conflicts I have seen on the ML lately and it is way too easy to reflect rudeness back so yes I think everyone on here needs to get over it and work together politely. > This is what I want too. And this is why you do not want softworkz to > work on this feature. This patch series leads libavfilter into a dead > end that cannot evolve for what you want. This is why I have been trying to ask high level questions. His old subtitle filtering patchset would need a lot of rework to bring to the current codebase so starting over isn't a bad idea. I don't really care who works on or makes the commits for the code as long as the resulting code is clean, makes sense to other developers and accomplishes what everyone needs. There are structural changes needed for what I want and it would be good to find a solution that allows for functionality for additional processing options also. > On Tue, Jun 3, 2025 at 9:48 AM James Almer <jamr...@gmail.com> wrote: Please do not top-post. I was trying to figure out why you brought this up again, because I didn't think I was, but realized that Gmail was automatically making every reply a top post and hiding it from me... I'll do my best to reply with the right format. Plase let me know if any problems persist On Tue, Jun 3, 2025 at 11:02 AM Hendrik Leppkes <h.lepp...@gmail.com> wrote: > For a clean API in the future, we should start with a clean and clear > definition of public API, and not use it to solve > implementation-specific solutions in lavfi that should rather get > solved in lavfi itself, and not in the user-facing API. > And this is exactly what I've also tried to explain from day one that > this patchset showed up on the ML. How can we start this new conversation to properly define what work needs done before we get lost in the weeds again about specific implementations and libraries? I think a new public API and cli options/filtergraph definitions should be considered for handling ancillary data routing in general between stream types. What is the best way to start that conversation? Are any of the questions proposed by softworkz in the beginning of this thread relevant to that conversation yet, or do we need to establish the required changes in functionality first before discussing data structures and variable names? Zach _______________________________________________ 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".
