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

[Hendrik Leppkes]

On Sun, Sep 12, 2021 at 6:21 AM Soft Works <softworkz at hotmail.com> wrote:
>
>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Soft Works
> > Sent: Sunday, 12 September 2021 05:21
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH v5 00/12] Subtitle Filtering
> >
> > v5 Update:
> >
> > - Merge AVSubtitle into AVFrame
> > - Move FATE test adjustments to corresponding commit
> > - Move documentation updates to corresponding filter commits
> > - Remove mediatype parameter from av_frame_get_buffer2
>
> This patchset provides proof that merging AVSubtitle into AVFrame
> is doable and not far away to achieve. It obsoletes the need for
> a "subtitle api", as that purpose will be served by the AVFrame
> API. It might still make sense to add a number of functions for
> dealing with AVSubtitleRect (e.g. av_subtitlerect_alloc, _free)
> as these should probably be ref-counted to avoid copying.
> I have added a minimal internal ref counting which serves the current
> use cases, but I'm open to suggestions..
>

The key that this patchset does not do however is preserve compatibility.
As mentioned in another thread, we don't just change APIs, certainly
not overnight, and basically not ever. We introduce replacements, and
deprecate the old ones (and remove after a grace period)

That means if my application does not use deprecated functionality, it
has to continue working after this patchset - and that is absolutely
not the case.

So what needs to happen is that existing subtitle functions need to
continue to be functional and unchanged, including all structures and
whatnot. They can be deprecated and removed in ~2 years
This fact alone makes it also easier to split such changes into
smaller pieces, because you only add, you don't remove or replace.

So back to small atomic commits, which is easy if you don't update
everything in one go, because you are not allowed to anyway. Old
functions have to be preserved.

Internally, there should be a compatibility layer. I would recommend
at first not changing encoders and decoders internally, and instead
build the compatibility so that it uses the old internal API to feed
the new external API.
This can be changed and reversed in a follow-up change later.

Also, yes to refcounting allocations.

- Hendrik