[FFmpeg-devel] [PATCH 4/9] avfilter/overlay_subs: Add overlay_subs filter

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Thursday, 19 August 2021 15:24
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/9] avfilter/overlay_subs: Add
> overlay_subs filter
> 
> Soft Works (12021-08-19):
> > No, I don’t think this would be ridiculous. I just wasn't sure how far
> > I should go with the initial patchset. I also had an scopy filter
> > that I had removed before submitting because it wasn't needed from
> > a proof-of-concept perspective.
> 
> Well, it is already ridiculous, and more importantly annoying for both
> users and developers to have all the utility filters duplicated for both
> media types, it would be even worse to have them triplicated.
> 
> So I will state it plain an clearly:
> 
> I consider that negotiating the media type is an absolute prerequisite
> for any project of adding support for more media types in libavfilter.
> 
> This is not that hard to do. As I pointed, I already started working on
> it. It would have gone faster if there were other people interesting in,
> reviewing the code trustfully and offering useful suggestions.
> 
> > I'm not sure what you mean exactly, probably I should take a look
> > at your code that you mentioned.
> 
> That would be a good idea for the sake of the discussion.

Will do.

> > We already have AVSubtitle which is understood by encoders and decoders,
> > so I see no reason to convert this back and forth to something different
> > just for carrying around by AVFrame.
> 
> There have been extensibility issues raised against AVSubtitle, and in
> particular AVSubtitleRect. Reworking this API has been considered
> necessary for a long time.

Yes, but I think that a step-by-step approach makes more sense
than raising a bar that high that it becomes hardly possible to
Surpass.

> 
> > I need a solution and the discussion last year ended up nowhere after
> > discussing some freaky details about which I (and probably most others)
> > don't care at all.
> > From that experience I wanted to avoid this to happen again.
> 
> Not taking into consideration what was already said on a subject is
> really not a good way of making the discussion progress.

There are substantial and practical concerns and there are concerns
that are of rather academic nature that might be valid in some way
but don't have much practical relevance. 
That's what I meant.

> Every once in a while, we have somebody arrive with a series of patch
> and make a tantrum "but my code works and I want MY feature NOW!"
> without consideration for users who may want to use the feature a little
> differently or the developers who will have to keep that feature alive
> continue developing FFmpeg around it.
> 
> I hope you do not intend to be that guy.
> 
> Extending FFmpeg, especially for a feature that central, requires
> looking at the big picture, and looking at the big picture requires
> having spent time maintaining code, developing different features and
> interacting with users.
> 
> > I don't think that my patchset is going a totally wrong way, even though
> > some things might need adjustment, but it is clearly just a step and
> > not arrival at a finish line.
> 
> Even if it not going in "a totally wrong way", since what you are doing
> is part of the public API, any mistake made now will bug us for a very
> long time.
> 
> Therefore I insist we are extra careful not to make mistakes.
> 
> > The primary motivation for submitting this right away as is, is to
> > avoid this do be discussed to death once again and make a step that
> >
> > - doesn't break anything
> > - allows things to work that haven't been possible before
> 
> - is part of the public API
> - makes it harder to maintain libavfilter
> 
> "But my code works and I want MY feature in NOW. (And I won't be around
> long enough to have to maintain it anyway.)"
> 
> Please do not be that guy.

I'm both. I am the guy that wants those features NOW.
But I'm also the guy who acknowledges your concerns and who
wants to collaborate with you (and anybody else who might chime in)
to come to a solution that is acceptable for all sides.

> I am very happy if somebody wants to seriously work on subtitles in
> libavfilter, but seriously is an important word here. If it was as easy
> as slapping a few pieces of code around like you did, I would already
> have done it years ago.

Why haven't you? I would have welcomed and supported that!


The intention of my submission was to demonstrate that it doesn't
take that much to come to a working solution.

Like I said above: In the past, the bar has been raised so high that
it has caused any progress to stall or die.

I'm not considering my submission as the one and only eat-it-or-leave-it
solution and I'm ready to work on it and get it into an even better 
shape, as long as it leads to a solution and not into another dead 
end.

> The first step in libavfilter is to refactor the negotiation to make the
> media type negotiated. It is already started.

I'll look into your work and get back shortly.

Thanks,
softworkz