[vlc-devel] Offsets, plane_CopyPixels() and deinterlace

[Juha Jeronen]

Hi,

On 05/08/2011 02:44 PM, Laurent Aimar wrote:
> Hi,
>
> On Sun, May 08, 2011 at 02:45:25AM +0300, Juha Jeronen wrote:
>>     On Sun, May 1, 2011 at 4:55 PM, Laurent Aimar <fenrir at elivagar.org> wrote:
>>
>>          If you use i_visible_*, you must also use i_?_offset (which define the
>>         top-left of
>>         position the rectangle inside the video surface).
>>
>>
>> i_x_offset and i_y_offset in video_format_t? Thanks Laurent :)
>  Mmh, in fact I mixed up things, and so did a wrong remark in my review :(
>  From video_format_t, i_visible_width/height go with i_x/y_offset but they are
> not related to plane_t::i_visible_width/height.

Ok, I see.


>  plane_t::i_visible_* are there to know which part of the memory planes can at
> most be displayed. Usually there are different than the whole surface due to memory
> alignment constraints (like mod 16 for SSE2 or to be alligned on a macroblock).
> Those values are decided when the picture is allocated and they usually don't change
> for a given picture pointer (but they can change, like in direct3d buffers).
>
>  While video_format_t:i_visible_width/height and i_x/y_offset are more a 'hint'
> regarding what will be actually displayed. A filter should update filter_t::fmt_out
> if needed to ensure that the allocated pictures get the right value. I don't think
> a filter should limit to this area as dynamic crop setting is supported.

Ok. So basically, it's fine in a filter to handle the
plane_t::i_visible_* area - which should include margins and only adjust
for memory alignment - and let the cropping be performed elsewhere. In
this case the current version of deinterlace is correct.

Thanks for the clarification :)

 -J