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

[Hendrik Leppkes]

On Tue, Mar 3, 2020 at 10:53 AM Anton Khirnov <anton at khirnov.net> wrote:
>
> 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.

And a bunch of functionality duplicated because we've been
discouraging avpriv use of such things for years now.

- Hendrik