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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Mittwoch, 4. Juni 2025 22:42
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Hi Nicolas
> 
> On Wed, Jun 04, 2025 at 09:13:44AM +0200, Nicolas George wrote:
> > Zach Swena (HE12025-06-03):
> [...]
> >
> > > 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.
> >
> > His old filtering patchet was broken beyond repair, and nothing changed.
> >
> > Just to give an idea of my position on the topic: during one of the
> > first VDDs, possibly the first one, I co-hosted with Ubitux a
> > multi-hours brainstorming session on the matter of subtitles in
> > libavfilter. That is how much I want to keep subtitles out of
> > libavfilter, and that is how little time I have spent on it anticipating
> > problems and finding solution.
> >
> > When I say that softworkz's approach is broken, I know what I am
> > talking about.
> >
> > It is broken in three ways.
> 
> Is it possible to create 3 testcases that one can just copy and paste to the
> command line to see these 3 problems ?
> 
> If its possible, it would clearly show the problems and avoid a never
> ending disagreement
> 
> thx
> 
> [...]
> 
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB


Hi Michael,


He won't do that because he can't. At best, he will come up with a 
non-implemented feature.

All the crucial utility filters are implemented already:

sbuffersink, sbuffersrc, strim, snull

(here's no ssetpts yet, but that's just a missing feature and not crucial)



Also, this behavior is a pattern he has repeatedly used in the past 
already: He talked about "flaws" all the time and never got really 
specific when asked for it.

He played in the same way as today: like "when you don't know which
flaws I mentioned, then you are not suitable to do the task" etc.

Most ridiculously, after I had nailed it down to a point where it
was clear that he couldn't name any, he changed his statement to say
he "could find flaws if he would do a full review"

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-July/299284.html


And here he had invented a reason against my sf patchset in 2022:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298407.html

He would have something important to submit and because of that,
my patchset cannot be merged.

He has never submitted this, what he had presented as a blocking 
reason.


The truth is that what he does here is just about producing a 
lot of steam, making it _sound_ like something profound while 
it is just hot air without substance.

In the past, I made the mistake that I tried to respond at a 
technical level, but at the end, nobody was able to understand
who is right and who is wrong.

Talking about specific cases and examples is the way to quickly
reveal for every other reader that there's no substance behind
his claims.

Thanks
sw