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

[Paul B Mahol]

On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin <tjoppen at acc.umu.se> wrote:

> 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.
>
>
Than why you are so called maintainer of thing you do not want to maintain?



Looks like some relatively "new" devs are completely failing to see the
point of FFmpeg.

And they are extremely ignorant of reality they live in all together.


If for whatever reason you do not want/like some code in FFmpeg then just
leave.





> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>