[MPlayer-dev-eng] video filter layer

[Arpi]

Hi,

> On Sat, Apr 21, 2007 at 08:43:04AM -0400, kiriuja wrote:
> > On Saturday 21 April 2007 02:27 Bobby Bingham wrote:
> > > As part of that, I'd like to ask all the MPlayer developers about your
> > > experiences with libmpcodecs.  What are some of the things you think it
> > > handles better than the competition.  More importantly perhaps, what are
> > > some of the areas where it could use work?  Are there any things that
> > > just flat out can't be accomplished with it?  Or can't be done as easily
> > > or effectively as they should?
> > 
> > I'm not an MPlayer developer, but from what I know video filter insertion
> > or removal on the fly is still not possible. From the point of view of a
> > frontend like KPlayer this is the biggest limitation on the filtering side
> > of MPlayer.
> 
> i think it should be possible to rebuild the whole filter chain (dont ask me
> how exactly i would have to RTFS too ...)

The top-level filter (vf.c) does it, whenever the codec parameters
(aspect ratio, resolution etc) changes or new decoding starts.
It is possible to rebuild the chain, but i think most of the filters
are buggy/broken and would not handle a re-config case when new filters
are inserted after a successful config()...  anyway the whole libvf
is quite broken, even i did not understand how it works after a while,
so makning stable and bugfree vf filters is simply impossible :)

> 
> and inserting/removing without complete rebuild is generally tricky anyway, 
> independant of the filter API
> 
> just think of changing image size, changing pixel format, changing
> availability of slices, direct rendering, ... as the filter graph is changed

sure, the only clean way of changing the filters (ie. inserting/removing
new ones) is re-initializing the whole chain.

> also what would happen with filters which use previous frames, the frames
> they saw no longer match the new filter graph ...

in these cases the previous frames should be dropped, ie. reinit should
do teh same as the initial init/config call. i think such filters are
only the 3d denoiser and the various frame/field insert/remove (telecine,
deinterlace etc) variants. maybe also some motion-detection filter if any.

> so IMHO complete rebuild is ok for insert/remove, unless its easy to just
> insert/remove a filter with the new API ...

agree.
support for complete rebuild/reconfig should be there anyway, for the
file formats allowing on-the-fly size/format/aspect changes (like image
sequences, mpeg streams, some quicktime, dvd)...

> and of course a generic conditional wraper filter which could feed frames
> through another filter or let them pass unfilterd would be cute, something
> like:
> 
> in--->generic_cond_filter--->out
>           |         ^
>           v         |
>          foobar_filter

i dont quite understand what is it good for? disabling a filter on the fly?
what if the filter changes size etc...

anyway we (you) should decide if want to support filter trees/branches,
or just linear filter chains. the later is simpler and i would vote for
that, fut for G2 we had multi-input filters in mind...

i'm interested in discussing and implementing a good new filter api,
and i'm volunteering to help porting the mplayer filters too.

A'rpi