[FFmpeg-devel] SDR lib comments

[Vittorio Giovara]

On Thu, Sep 28, 2023 at 3:28 PM Michael Niedermayer <michael at 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