[MPlayer-dev-eng] [PATCH] mp_image flags in filters
Ivan Kalvachev
ikalvachev at gmail.com
Thu Jul 28 12:40:54 CEST 2005
On 7/28/05, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> vBlur(dmpi->planes[0], dmpi->planes[0], mpi->w,mpi->h,
> dmpi->stride[0], dmpi->stride[0],
> vf->priv->lumaParam.radius, vf->priv->lumaParam.power);
>
> vBlur operates only on dmpi (i.e. also reads from it)!
>
Fair enough. commit and bloxblur changes.
> > > > divtc - commit that, it does reading and the other get_image() do use readable.
> > >
> > > I really thought the readable in get_image is something completely
> > > different, it forces the mp_image you get as _input_ to be readable,
> > > whereas readable in vf_get_image concerns the output image (i.e. the one
> > > you write into).
> > > Or what do I misunderstand here?
> >
> > READABLE means that the filter will perform not only write but also
> > read operations in this buffer. (e.g. like smartblur, that uses
> > sws_scale to blur and then compares original and result images).
> > So if next filter is vo and it have direct access to video memory that
> > is slow on reading, then vo will not give direct buffer and vf will
> > use mem-allocated one instead.
>
> I was specifially talking about the difference when adding READABLE to
> the flags in a get_image function vs. when adding it whe calling
> vf_next_get_image int the put_image function.
> The former controls what kind of mp_image the filters before get, so
> here I think READABLE must be set for all filters that do _anything_
> with the image at all.
No, you are confising it with PRESERVE.
Well, that's one of the drawbacks of the current video system, it
mixes request flags with information/imperative flags.
There is no sense for an filter to get image with cleared READABLE, as
it MUST read from it, no mather what!
Happy Coding
Ivan Kalvachev
iive
More information about the MPlayer-dev-eng
mailing list