[MPlayer-dev-eng] [PATCH] mp_image flags in filters

[Ivan Kalvachev]

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