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

[Nicolas George]

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.

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

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

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

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

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210819/2daae06e/attachment.sig>