Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up

From: Zach Swena <devlist@rlb.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
Date: Tue, 3 Jun 2025 11:34:17 -0700
Message-ID: <CANJxsBnxkH75YmNOkkXa+rv6Ch+SqsXjGEqfKrmNrwb11uSBuw@mail.gmail.com> (raw)
In-Reply-To: <CA+anqdwVei3k-cxhhOhBi+u+1neij1aTviTXDJTA4iz3iKE0rw@mail.gmail.com>

On Tue, Jun 3, 2025 at 10:59 AM Nicolas George <george@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 <jamrial@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.leppkes@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-request@ffmpeg.org with subject "unsubscribe".