On Sun, Sep 12, 2021 at 6:21 AM Soft Works <softwo...@hotmail.com> wrote: > > > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Soft Works > > Sent: Sunday, 12 September 2021 05:21 > > To: ffmpeg-devel@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
