[FFmpeg-devel] Splitting or merging libraries (was: Status and Plans for Subtitle Filters)

[Anton Khirnov]

Quoting Hendrik Leppkes (2020-03-03 10:23:02)
> On Tue, Mar 3, 2020 at 2:19 AM Vittorio Giovara
> <vittorio.giovara at gmail.com> wrote:
> >
> > Whether you like it or not, there is value in designing separate tools and
> > implementing separate tools and libraries for different use cases: even
> > though the ffmpeg suite of library is closed together because they pertain
> > the same subject (multimedia) it makes a lot of sense to keep them separate
> > and try to identify portions of code that could work well enough in a
> > library separated from the rest.
> 
> Certain generic functionality may benefit from that, like, there is no
> reason a bitreader or IO couldn't be separate if we really wanted to.
> 
> On the other end of the spectrum however, the most offending parts
> right now are very specific codec-internals which are needed both in
> avcodec and avformat, because proper (de)muxing will often require
> very technical details about a codec thats usually only found in
> decoders. There is a concrete overlap here on very detailed technical
> functionality. One could argue that we should just make it public as
> well, but really, does anyone really want the reality of dozens if not
> hundreds of public API calls and tables that only server extremely
> niche requirements, but would end up cemented in API for a long time,
> with very questionable use to the API user?

That is a MASSIVE overstatement of the problem. There are about 50
functions/tables in about 20 headers. Some of them inline. Some of them
could be made inline. The rest, in my opinion, should be exported as
proper public functions. If they are useful to libavformat, they can be
useful to other callers as well. From libavcodec's POV, libavformat is
not in any way special.

-- 
Anton Khirnov