[FFmpeg-devel] [PATCH] remove libmpcodecs

[Stefano Sabatini]

On date Wednesday 2013-09-18 17:23:50 +0000, Paul B Mahol encoded:
> On 9/18/13, Stefano Sabatini <stefasab at gmail.com> wrote:
[...]
> > As for qp, ilpack, and softpulldown I can't really say, but I'm
> > willing to keep the wrapper unless we port all the remaining filters
> > unless there are strong reasons not to keep them (not useful, not
> > relevant, or completely broken by design).
> 
> qp is broken - it does nothing.
> softpulldown was broken too, but I was (very for Carl) stupid and added
> hack to wrapper.

> ilpack - wtf is that?

ilpack[=mode]
 
When interlaced video is stored in YUV 4:2:0 formats, chroma
interlacing does not line up properly due to vertical downsampling of
the chroma channels.  This filter packs the planar 4:2:0 data into
YUY2 (4:2:2) format with the chroma lines in their proper locations,
so that in any given scanline, the luma and chroma data both come from
the same field.

<mode>
Select the sampling mode.
0: nearest-neighbor sampling, fast but incorrect
1: linear interpolation (default)

More interlacing stuff. Maybe some MPlayer developers can comment on
it (it seems I can't get any reply from the original filter author).

> >
> > I know that removing large chunks of code can be relieving, OTOH
> > keeping and maintaining the code as is should not cause much trouble
> > so it should be kept.
> 
> Nobody maintains that code, mainly because for easy (copy/paste) changes
> that come from mplayer.

?

AFAIK Michael maintains the mp wrapper code, and so far
mplayer/libmpcodecs doesn't receive many commits so there is not so
much to merge (and libavfilter native code is in many cases more
featureful-complete and more correct).

> >
> > I remember that when we removed vhook many complained for the missing
> > features with no ready replacement, nor people who complained lent any
> > help to implement the missing features, so that was not useful not
> > even for the developers implementing them.
> 
> You are mixing apples and oranges here. Did any user (except Michael)
> wanted libmpcodecs merge?
>
> From my experience most user that use mplayer filters are actually
> using mencoder. And there are not many of such users.

>From my point of view the main benefit of the wrapper was the
possibility to easily compare port and original code. The drawback was
that we insisted in porting each and every single feature, resulting
in somehow bloated code (well, tinterlace is an example), and filter
code duplication (lot of pp filters nobody really know how to properly
use), and in some cases bad defaults (tinterlace, again).

Also stating that only mencoder users use those filters can't be
proved, and we have many counter-examples so in general it cannot be
considered true.

>From my point of view, the most striking feature of libmpcodecs is the
number of filters dedicated to deinterlacing and post-processing,
which probably reflects the needs of the original authors (which might
not correspond to most actual use cases).

Consider that one of the main objectives of the wrapper is to enable
users to get rid of mencoder. Hopefully we are going to get rid of the
mp wrapper soon. I was hoping at some point that MPlayer was going to
rely natively on libavfilter, but this unfortunately never happened.
-- 
FFmpeg = Frightening and Fundamentalist Miracolous Peaceful Elegant Gorilla