mån 2022-08-22 klockan 14:52 +0200 skrev Nicolas George: > Tomas Härdin (12022-08-22): > > I'd actually argue that in that case we should link a library that > > implements IPFS, not split developer effort by trying to implement > > it > > ourselves. > > Is FFmpeg meant to be just a convenient set of wrappers for existing > libraries, then?
It Depends. If we could rid this project of all NIH:isms that would be great. Only keep that which is strictly better than other existing libraries, for example higher-performance decoders. For everything else we can do subtree merges if people still insist the project should build "out of the box". One excellent example of this is the recent discussion around libxml2. I maintain that developer effort should go toward improving libxml2. Only if that is a lost cause, if libxml2 is hopelessly slow or irredeemably buggy, only then would a new XML parser be justified. It seems most developers understand this. But for some reason the notion that the same applies to *all* parsers, including decoders and demuxers, this notion is hard to swallow. And similarly for encoders and muxers. I have yet to see a justification that is anything but cargo culting. 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. Code is a liability. We should seek to have as little of it as possible. /Tomas _______________________________________________ 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".
