[MPlayer-dev-eng] vf.c & PEREFER_ALIGNED_STRIDE

[Arpi]

Hi,

> > mpi->width is with of the allocated buffer, not the displayed inage,
> > it's mpi->w ...
> well,well,well. I see the picture. This explains and the
>  MP_IMGFLAG_ACCEPT_WIDTH, or at least gives a clue.
> I thought that mpi's x,y,w,h are used for direct render method 2.
> And they are partial - e.g. describing slices. In case of MB w,h could be
> e.g.16 and width,hight will contain the dimensions of the whole image.
> You agree that there is no other way to understand the whole visible
> width/height. But as long as vo system doesn't support dr2 it is not
> issue.

actually ->x, ->y are not used (yet). they were added for offset (when with
have a big width*height buffer and soem small image in the middle of it,
then you could define the visible area by x,y and w,h)

> > how do you imagine stride>(buffer)width to be implemented? malloc with
> > holes?
> memalign(height*stride); ? I belive that vf_flip won't pass negative
> stride here, but an abs() will fix that too.

i meant that hod do you want to allocate a buffer to provide a given stride
without increasing the buffer's width?
(remember: width = buffer width not the image width)

the main problem seems that you don't understand the naming convention (ok
it isn't relaly a convention just my brainstorm when creating mp_image.h :))
of libmpcodecs...

btw MP_IMGFLAG_ACCEPT_WIDTH is unrelated, it means the codec/filter accepts
stride, but only at pixel boundaries, ie. when stride%bpp==0
since mpi->width=stride%bpp it's ised in get_image() implementations.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
    "However, many people beg for its inclusion in Debian. Why?" - Gabucino
  "Because having new software in Debian is good." - Josselin Mouette
"Because having good software in Debian is new." - Gabucino