[FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

[Tomas Härdin]

ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer:
> On Wed, Aug 24, 2022 at 06:35:04PM +0200, Tomas Härdin wrote:
> [...]
> > 
> > This goes especially for formats like MXF, which I have made the
> > case
> > on here multiple times that we should not maintain our own decoder
> > for,
> > but rather pull in bmx. And everytime I have suggested this it has
> > been
> > made clear that such patches would be rejected. And so MXF
> > developer
> > effort is split.
> 
> Is there a need for mxf (de) muxing without other containers ?
> If the awnser is (mostly) no then the problem is not FFmpeg wanting
> its
> own but rather that someone maintains mxf code outside ffmpeg.

I think you missed my point about subtree merges

> > Code is a liability. We should seek to have as little of it as
> > possible.
> 
> Look back at tesla, "vertical integration is a liability", that
> sounds
> wrong. Quite the opposit, companies that split everything out seem to
> do
> significantly worse.

This again has to do with things like economics of scale. When it comes
to inter-company exchange, profit acts as a fetter on productivity.
Tesla has to pay not just the cost of Samsung's 18650 cells but also
Samsung's profit. These are two reasons why vertical integration can
make sense.

If Tesla could copy Samsung's 18650 production line, Samsung's capital,
literally for free then they would have done so from day one. This is
what free software is - a kind of commons capital that can be copied
gratis.

> It doesnt mean everything should be done internally
> but simply because some external work exists doesnt mean we need to
> use it
> and then have to maybe maintain a codebase that we do not know and
> that
> noone is willing to maintain and that noone from FFmpeg even has
> write
> access to.

Obviously we wouldn't pull in things we have zero access to. We could
for example subtree merge specific releases, and set up the build
system so that we can either use that or an equivalent shared system
version. One limitation of this approach is that new features in say
bmx can't be merged immediately but has to wait for the next official
release of bmx. But this can be handled by having a branch where
changes in our codebase that depend on changes in bmx coexist, and on
bmx's next release they are merged into master. Pressure could be
applied from our end on bmx to release early if the feature is a
pressing one.

> Next some platforms may carry old versions of that external
> code, some might not carry it at all.

Good thing we could build those dependencies ourselves then, if we set
up the build system correctly.

> Also we have regression tests, external libs make that impossible
> as the version of external libs can change the behavior. Again this
> is a issue for mxf maybe less so libxml. You can also see that we
> have no
> tests involving  any of the external encoder libs, for that very
> reason.
> With each external lib that is needed for core features this would
> become a quickly growing problem

Testing is certainly a challenge, but almost certainly easier than
reimplementing certain formats and codecs poorly, especially MXF.

/Tomas