On Tue, Mar 3, 2020 at 10:53 AM Anton Khirnov <an...@khirnov.net> wrote: > > Quoting Hendrik Leppkes (2020-03-03 10:23:02) > > On Tue, Mar 3, 2020 at 2:19 AM Vittorio Giovara > > <vittorio.giov...@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 _______________________________________________ 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".
