[MPlayer-dev-eng] video filter layer

[Michael Niedermayer]

Hi

On Sat, Apr 21, 2007 at 10:31:57PM +0000, Arpi wrote:
> 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 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?

yes


> what if the filter changes size etc...

it wont work :)

i was suggesting it because someone added hacks into all deinterlace
fiters to disable them on a keypress
the way this was implemented just disables the first deinterlace filter
in the chain

a generic filter wraper would avoid requireing changes in the deintelace,
postprocess, denoise, ... filters to bypass them and it would avoid problems
if there is more then one such filter in the chain

syntax could be something like -vf gen_bypass=d:{foobarfilter=1:2:3}
and then simply pressing 'd' would disable/enable the foobarfilter ... 


> 
> 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...

id like arbitrary filter graphs to be supported that is as long as they
dont deadlock themselfs or run out of memory due to frame buffering
requirements ...
iam of course not against droping this goal if it turns out to be too
difficult to achive ...

also even with a API based on a single chain its possible to add some
support for more complex filter graphs by simply ading a small set of
filters which can store and load frames to some global "stack" and perform
operations with frames from that and an filter to pipe frames into another
process and one to receive one from a pipe from yet another process
actually i wanted to implement these for libmpcodecs but iam too lazy :(


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

:))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070422/a12561f6/attachment.pgp>