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

[Reimar Döffinger]

Hi,
On Thu, Jul 28, 2005 at 12:40:04PM +0300, Ivan Kalvachev wrote:
> On 7/28/05, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > ??? Why would setting readable prevent DR?? It would only prevent DR
> > into video RAM, which is correct, video RAM is _much_ too slow, even for
> > reading just a few bytes. At least that's how I understood it.
> 
> I didn't spot where boxblur reads from the gotten image. That's why I
> don't think READABLE belongs to this filter. Well if I am wrong.. show
> me the code :)

Ok, that's a different point *g*
        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)!

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

> Well I guess you now know what's the problem of h.264 decoders that
> can have 16 prediction frames.

I now know why h264 if a bad choice for testing a DirectRendering
implementation *g*

Greetings,
Reimar Döffinger