[FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami

[Ronald S. Bultje]

Hi,

On Mon, Jan 12, 2015 at 10:07 AM, compn <tempn at mi.rr.com> wrote:

> On Mon, 12 Jan 2015 08:24:35 -0500
> "Ronald S. Bultje" <rsbultje at 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