[FFmpeg-devel] [PATCH] configure: deprecate libpostproc and pp filter

Michael Niedermayer michael at niedermayer.cc
Fri Apr 27 18:20:50 EEST 2018


On Fri, Apr 27, 2018 at 12:39:13PM +0200, Paul B Mahol wrote:
> On 4/27/18, Michael Niedermayer <michael at niedermayer.cc> wrote:
> > On Fri, Apr 27, 2018 at 02:36:05AM +0200, Michael Niedermayer wrote:
> >> On Fri, Apr 27, 2018 at 12:08:16AM +0100, Josh de Kock wrote:
> >> > The postproc library is only used in a single filter, so should be moved
> >> > into the filter itself if the filter was to stay, but the filter has all
> >> > of its internal filters now in lavfi itself. (Also it's a bit weird to
> >> > have a separate library of filters which is used in a filter in the
> >> > filter library).
> >> > ---
> >> >  configure | 6 ++++--
> >> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> That patch is a bit surprising.
> >> What prompted you to write this ?
> >>
> >> Also, dont you think that before suggesting to deprecate a lib it would
> >> make
> >> sense to talk with the author and maintainer of the library in question ?
> >>
> >> Either way, the first question to ask would be
> >> "why was/is it a seperate library"
> >> I think, you do not know,
> >> And you should understand why things are as they are before suggesting to
> >> deprecate, move or otherwise change them
> >
> > Elaborating on this a bit
> >
> > The first step is to understand the current state of things, why is
> > libpostproc where it is. (it seems noone asked the maintainer / author)
> >
> > after its understood, next is to discuss whats the best thing for the
> > project
> > Some discussion occured on IRC but people neither understood why its in a
> > seperate lib currently nor where anyone who maintains or who wrote it
> > involved
> > in this discussion, making this discussion a bit headless and blind
> > I also think IRC is not ideal for this discussion as only a small subset
> > of people will be there when something is discussed ...
> >
> > Once a consensus is reached what is best to do, that should then be
> > implemented.
> > We have not reached this point nor has anything that was suggested been
> > implemented.
> >
> > The last step then is to deprecate any previous places that are no longer
> > relevant. So this patch is premature, other steps have to be done first
> 
> Libpostproc was removed from Libav, you failed somehow merge that change?
> 
> 
> They moved it to abandoned repo.
> 
> 
> We should not follow that.
> 
> 

> Libpostproc is very small in size and trivial GPL code and all funcionality
> should be moved to pp filter in libavfilter.
> 
> No point to have separate library nobody really uses.

Well, thats one direction it could go.
But still noone asks why its a seperate lib ?

Its long ago and there were multiple reasons, the one still relevant today
is that lossy decompressed moving pictures and images is very widespread.
And postprocessing that often improves its subjective and
objective quality

So there are a lot of applications and libraries which would benefit
from using "postprocessing".

And libavfilter is quite big, a small lib that is just for postprocessing
lossy decompressed video would fit this usecase better.

I think a big problem we had was that alot of software which would benefit from
this code isnt aware of it.
But i may be wrong, libpostproc was never "advertised" by anyone as being
usefull to improve the quality of low bitrate videos, and jpegs and other
similar lossy compression schemes.

I dont know what is the best way forward but simply moving it into
a filter in libavfilter alone seems to make it much harder to use for
many outside ffmpeg.

Of course that can be a great idea together with making libavfilter more
modular. If for example an application which wants to use just one filter
from libavfilter could do this without pulling anything else in not even
most of the core and just use that one filter then moving postproc
into a filter in libavfilter would be possibly even better than having it
in a seperate lib (which is less modular as it would contain multiple
related filters)

Its really a question what people prefer what makes most sense and what 
has volunteers to do the actual work.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180427/c91d35c8/attachment.sig>


More information about the ffmpeg-devel mailing list