[MPlayer-dev-eng] pts and video filters
Ivan Kalvachev
ikalvachev at gmail.com
Sat Jan 28 21:42:23 CET 2006
2006/1/28, Rich Felker <dalias at aerifal.cx>:
> On Fri, Jan 27, 2006 at 04:25:34PM +0200, Ivan Kalvachev wrote:
> > 2006/1/26, Michael Niedermayer <michaelni at gmx.at>:
> > > Hi
> > >
> > > attached patch outlines how that could be done, alternatively a pts field
> > > could be added to mp_image_t
> > > oppinions?
> >
> > the mp_image could be allocated once and used in many filters (DR).
>
> NO, this is not how the system works. the mp_image is associated with
> the link between two filters and must never be used in another
> context, even if the same underlying buffer is used.
>
> This limitation applies not only to the current architecture (which
> sucks), but to any properly-designed architecture as well. However
> it's not a limitation at all since two distinct mp_images could share
> the same allocation space for the actual pixel data.
RTFS
vf.c::vf_get_image()
and
vf_vo.c:get_image()
You will see that when filter implements get_image() (that is used for
DR, as I hinted above) would not use their slots for mpi but return
pointer to the mpi allocated in one of the next filters where image
have been allocated (this includes vf_vo filter).
I'm still not sure what behaviour is better. e.g. the buffer do belong
to the filter that have allocated it and making tricks would not be
recommended (e.g. if they involve putting frame twice while changing
it) .
Hell, mplayer filter system is so brain damaged!
More information about the MPlayer-dev-eng
mailing list