[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Original]
Re: Re: Re: [MPlayer-dev-eng] libvfilter-0.1.tar.gz
> You are a bit late because you have already rewritten it. But we
> have a filter layer in cvs now with a (IMHO) quite good design and
> that is a good thing. It just feels kind of stupid to throw away ~2k
> lines of working code and replace it with another implementation
> which basically has the same design.
probably i'm becaming to LGB (the guy who rewrites everything, including the
whole dosrun, and mplayer gui among other bug things) :)
> > > The runtime support is untested but the code is there. Anyway the
> > > data structure used to store the filters should be an implementation
> > > detail of the filter layer so it should be possible to change it
> > > without touching the filters.
> > i don't really understand this - why do you need to change filters now?
> I tried to say that what kind of data structure we use to store the
> filter chain don't matter much as long as the filters aren't aware
> of it.
filters don't have to know about this field in vf :)
it is not set by the filters, and is not readed / used by the filters.
> Anyway a linked list looks like a good choice to me now.
> > > I think vf_forward_config is unecessary. IMHO it is better to pass
> > > pointers to width, height, format etc. Imagine a situation when we
> > > want to insert a filter which don't change width, height, format,
> > > d_width, d_height or any other of the config parameters. In this
> > > situation we don't need to (re)config the filters that are after the
> > > filter we are about to insert. If we have vf_forward_config we will
> > > always (re)config everything after the filter we insert. In the same
> > but what happens, if a given filter needs to call child's config() more
> > than once? in your way, you can manipulate parameters but cannot avoid
> > calling child's config or call it twice with different params.
> Why would you need to call config more than once?
> And why would you not want to call it at all?
more than 1? maybe the first call fails, and we try to call again with
different parameters - would be usefull for some autodetection maybe
no concrete idea yet - but keep it for the future, may be useful later.
no call? maybe we'll reinit some plugins, but it may find that parameters
of child filters didn't change so no new config() is needed.
of course this can be reached wiht your way too, i just find my method a bit
> I am asking out of curiosity, vo_forward_config is not as bad as I
> thought it was when I saw it the first time.
A'rpi / Astral & ESP-team
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu