[FFmpeg-devel] [PATCH v5 00/12] Subtitle Filtering

[Michael Niedermayer]

On Thu, Sep 16, 2021 at 12:20:17PM +0200, Nicolas George wrote:
> Hendrik Leppkes (12021-09-15):
> > Or perhaps some people have a day job, a life and other obligations
> > that prevent them from spending time on FFmpeg every day, especially
> > outside the weekend.
> > But no, that can't be it, surely we are all just evil. /s
> 
> > Nothing here is being invented. You are trying to push a major API
> > change to the core functionality of our libraries, these rules on how
> > to do API changes on that level (or any level, really) have been in
> > place and followed by everyone for years and years.
> > If you don't believe that, feel free to check how any other major API
> > change was handled in the past. Because the overall pattern is always
> > the same.
> > 
> > Do you think I'm the only one thinking that way, only because I spoke
> > up? The set certainly wouldn't have been applied if I hadn't said
> > anything, it would've just sat there. Maybe someone else might've come
> > forward eventually.
> 
> Thank you for having the patience and taking the time to explain this.
> 
> > As for the actual subject:
> > - Part1, add subtitles to AVFrame in avutil. You can move
> > enums/structs to avutil as needed (eg AVSubtitleRect or whatever), as
> > long as they are still available the same way (eg. avcodec.h should
> > include any new avutil header with them, so user code works without
> > changes), but moving functions is a more tricky business, so we
> > usually make new functions and cleanup their naming convention in the
> > process, but I don't think any functions are involved here right now.
> > 
> > To dive a bit deeper into this, redundant fields should be removed,
> > actual subtitle data should be refcounted (with AVBuffers in
> > AVFrame->buf), all frame functionality need to properly account for
> > the new data type.
> 
> There is another point to consider when designing subtitles in AVFrame:
> since we intend it not only as a general API cleanup but as a prelude to
> extending the API with filtering and such, we must not only think about
> what is needed now, we must think about what may be needed later.
> 
> The few examples I have, not excluding questions I have not thought of:
> 
> - Right now, we have text subtitles and bitmap subtitles. But do we want
>   to be able to handle mixed text and bitmap subtitles?
> 
>   To this, I would say: probably no. But we should give it a thought.

This question can also be asked seperatly for API and implementation,
for example we may support mixed bitmap/text subtitles in the API but
not the implementation. The advantage would be that the API does not
need to be changed if we want to add support on the implementation side

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210916/f76c9b61/attachment.sig>