On Tue, 23 Jun 2015 11:05:31 +0200 Nicolas George <geo...@nsup.org> wrote:
> Yes, libavspellcheck! I used it as an absurd example, but if you think > carefully on it, it is not actually absurd. I think you're alone with this. libav* are for (de)muxing and decoding/encoding. That's why people are using it. Everything else FFmpeg does extremely badly, and thus is better done somewhere else. It all boils down to API and organization really. It wouldn't be much of a problem to add a separate git repo that contains libavspellchecker. This would be truly independent. But I know what would happen... you'd add subtitle support to libavfilter, and the spell checker would be implemented as a filter. We could have libavremotefileoperations too, but no, it will just end up in libavformat. Oh, and even if we had libavspellchecker or libavremotefileoperations, it would have to be part of The Big Git Repo. For some reason. Even though the sub-libs are supposed to be independent. (Totally.) Your arguments all make sense, but the way things will actually be done is different and usually terrible. (Just think about it. Things such as adding video outputs through a muxer API just because the original authors didn't know a better place for it. Using a muxer API for video output is absurd, but if you bang your head against ffmpeg.c enough, your brain matter becomes squished enough that it starts making sense.) Regarding bloat: distro versions of FFmpeg are typically extremely bloated. It's fun to watch: merely linking a C source file containing only a main function to Debian's build of libavformat will allocate at least 10 MB of RAM on program start. Bloat is bad because it adds up. And you can't escape it either. If you link to a distro build of libavformat, your program will use more memory and will take longer to load as it would if you'd compile it yourself. I'm also not sure why you think maintaining essentially dead code is hard. Hint: it is pretty hard if you actually want to make FFmpeg saner overall. Bloat is like the concrete that keeps entangled software entangled. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
