Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer <mich...@niedermayer.cc> a écrit : >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2023-09-23 18:43:44) >> > Is a seperate library really the right choice for SDR in FFmpeg at this >> > stage ? >> > >> > Also code can always be moved into an seperate library >> >> we've had postproc in the tree for ages, nobody maintains it or >> cares about it, yet it seems impossible to get rid of it. > >what maintaince does it need ? >i mean i know the code is ugly but what _needs_ to be changed?
This is rather disingenous, TBH. All non-trivial code needs maintenance. If there is no formal proof that the code is perfect, then it's probably bugged. And for the sake of the argument, if there were such a proof, it would need to be maintained as the code around changes, so either wayw that's maintenance. Then you also can't really ascertain that the code won't need fixes for future build environments and code auditing tools. And then you have all the more or less hidden costs of keeping code around, especially if it's unmaintained : people will enable it (if it's even disabled by default), hit problems and look for support. And as a downstream OSS application developer, I'd really rather postproc be officially and properly dropped, so I can justify dropping it downstream as well. But at least, postproc doesn't engender extra traffic on this mailing list much at all. More or less nobody here can or wants to review or test your SDR code. I think, more so than ffmpeg.git being ill-suited a source code repository for SDR because it is so niche and loosely related, ffmpeg-devel is simply not suited for SDR. The skills are not here, the time and motivation are not here, not to speak of the good will. If the project grows and develops to become better accepted as a fit for FFmpeg, it can be merged (like btrfs.git got merged into Linux, with full git history). Honestly I think that probably will never happen, especially not after at least two distinct attempts to make it a fait accompli in spite of FFmpeg-devel. But I'm not a medium. In the end, cool but controversial new features being rejected due to poor community acceptance, and continuing their life elsewhere, is quite common and mundane. It happened to me more than once (not in FFmpeg, obviously). >libpostproc implements part of ISO/IEC 14496-2 >(that is the spec for an MPEG-4 ASP decoder) > >its content could be moved in libavfilter and or the mpeg4 decoder >(there are arguments to be made for either) >but it doesnt belong in a lib external to FFmpeg. >(and in the process some bits probably can be droped as they > no longer serve a purpose compared to other filters) > >I have too many other things to work on to do a big refactoring of it >but if there are small bugs in it or questions about it i can look into them > >thx > >[...] > _______________________________________________ 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".
