Hi, On Mon, Jan 12, 2015 at 10:07 AM, compn <te...@mi.rr.com> wrote:
> On Mon, 12 Jan 2015 08:24:35 -0500 > "Ronald S. Bultje" <rsbul...@gmail.com> wrote: > > > Anything else? Why not just implement these in ffmpeg directly? > > because (i'm guessing) they are developing libyami with other projects, > not ffmpeg. > > i know everyone wants to reinvent the wheels here, but also that may > have a detrimental effect on development if nothing gets in except > ffmpeg-style-wheels. These are two extremes: every single C function should be shareable between any two random software projects, or we should have no dependencies at all. In the real world, we balance these extremes by the practical implications (benefits vs. risks) associated with it. - too big dependency tree (how long does it take you to build gnome? I know users don't care, but what if you're a dev? I'm a dev) - are talented developers likely to maintain the alternate codebase (as opposed to a hypothetical impl in our tree)? - are talented (app) developers likely to use ffmpeg if we use a lib's implementation, rather than our own? - will they be around in 5 years? will they fix bugs? security issues? portability issues? will they care about ffmpeg-specific exposed bugs in their code? vs. - how long will it take us to implement these features ourselves? - are we the right people to take on long-term maintenance of such a feature? - are talented (app) developers interested in such features likely to use it if we directly provide it, as opposed to through some other lib (which is linked into ffmpeg)? - are talented developers likely to help us maintain the feature in our codebase as opposed to the impl in another lib? It's very complex. I don't have straight answers to all of these. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
