On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer <mich...@niedermayer.cc> wrote:
> 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 ? > making sure that the library builds on all supported system, doesn't have security holes, etc or for packagers to bundle the library > libpostproc implements part of ISO/IEC 14496-2 > (that is the spec for an MPEG-4 ASP decoder) > We're going a bit off topic, but you're referring to something preceding H264 which means is something older than 20 years -- while old formats surely need to be supported against digital obsolescence, the code:functionality ratio is certainly not worth it (who uses ASP nowadays?), and as you suggest, it's code that could definitely live in libavfilter or libavcodec and not in a separate library. > 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 > I think the main reason libpostproc was mentioned is that we don't want a repeat of the history for SDR - so far you're only developer expressing active interest to work on it, and nobody knows if you will be continuing to work on it after releasing it, or for how long, and in which depth. The community at large (except one vocal member) seems to prefer that this code live in a separate repository, and not into ffmpeg mainline, so that we could avoid risking repeating history of having "ugly code" (your words) in the main repo for who knows how long, possibly forever. Once the SDR code is better defined, as library, executable or whatever, and there are users needing it, we could discuss bringing it back in FFmpeg, in a more defined and clean form. -- Vittorio _______________________________________________ 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".
