[FFmpeg-devel] [PATCH v20 02/20] avutil/frame: Prepare AVFrame for subtitle handling

[Nicolas George]

Hendrik Leppkes (12021-12-06):
> You just keep re-iterating that avfilter internals need it. And I'll
> just keep saying that avfilter internals shall not define public API
> design. I have not heard anything that justifies yet another field
> that has no benefit to the external public API - to the contrary even,
> a user would assume pts is pts, and he would be wrong.

Thank you.

I need to add that libavfilter internals need it only because it was
designed in a very naive way, by duplicating the frame instead of using
dummy frames without content.

This is not the only part of these patch series that are improperly
designed. Having two different filters to overlay subs depending on
whether they are text or bitmap is unacceptable. Not having any utility
filters (to shift or scale the times, to discard a segment, tu
concatenate subtitles along with audio and video, to print diagnostic
information, etc.) is also a big issue — and of course, triplicating the
boilerplate code for these filters is a big no. The way the
overlaytextsubs filter synchronizes its inputs is completely broken; it
works with the obvious test case, of course, but it will fail in any
complicated case.

I have made these comments before. I also have offered to help do things
properly. But instead of welcoming my help, Soft Works has rudely
rejected it. So now I am just looking with annoyance as people waste
their time helping Soft Works polishing patches whose design is wrong
from the core.

What everybody should be telling Soft Works on this subject is just
this: You do not try to redesign a major API of the project when you
have been in the project in just a few months and are still struggling
with our coding conventions and with configuring a mail client.

Especially not something that have been in project for more than a
decade. There is a reason I have not yet implemented subtitles
filtering, or offered it as a Summer of Code project: it is hard and has
a ton of prerequisite.

Now, if I knew I had the support of the core developers here, I could
serenely get on with implementing FATE tests for the negotiation system
and refactor it, which is the necessary first step before extending it
for a third media type.

Regards,

-- 
  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/20211206/5584aadd/attachment.sig>