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. > > 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. 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. Next some platforms may carry old versions of that external code, some might not carry it at all. It can become a mess when we need a specific feature and when distros like debian hava a policy that requires shared libs to be used when avaiable. So debian would remove a internal copy of a lib and force their shared lib to be used. At least that was the policy when i last looked years ago. And if we had a internal copy we would also have to do full security maintaince of that internal copy. Again that is code noone in FFmpeg knows. for libxml2 these problems are less likely to hit us as we likely never need a "new xml feature" but for a (de)muxer we quite likely will need the latests version on every platform. 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 thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
