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

[Ivan Kalvachev]

Arpi said:
> Hi,
>
>> >> then adjust stride to be macroblock aligned.
>> >> But we DO NOT change the stride! We change the width.
>> >> That is what i cannot understand!
>> >
>> > stride is calculated from width ~20 lines bellow in that func when
>> doing memalign() allocation.
>> Good. But the question remains. Why we change the width?
>> Look -> if a filter/vo ACCEPT_STRIDE, then it gets image that have
>> stride=width*bpp/8. And we change the width to perform this! No sense.
>> If a filter/vo doesn't accept stride then we may change the width, but
>> why change it elsewere?
>
> rtfm more
Where? In your mind? I can't, so i ask.

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


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

Best Regards
   Ivan Kalvachev