[vlc-devel] [PATCH] respect the x,y offset in Direct2D

[Rémi Denis-Courmont]

Le 2015-03-05 17:48, Steve Lhomme a écrit :
> On 05/03/2015 13:35, Steve Lhomme wrote:
>> On 05/03/2015 12:57, Steve Lhomme wrote:
>>> ---
>>>   modules/video_output/msw/direct2d.c | 4 +++-
>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/modules/video_output/msw/direct2d.c
>>> b/modules/video_output/msw/direct2d.c
>>> index f612262..6740a26 100644
>>> --- a/modules/video_output/msw/direct2d.c
>>> +++ b/modules/video_output/msw/direct2d.c
>>> @@ -213,7 +213,9 @@ static void Prepare(vout_display_t *vd, 
>>> picture_t
>>> *picture, subpicture_t *subpic
>>>
>>>           HRESULT hr = ID2D1Bitmap_CopyFromMemory(sys->d2_bitmap,
>>>                                                   NULL /*&r_src*/,
>>> -                                                
>>> picture->p[0].p_pixels,
>>> +                                                
>>> picture->p[0].p_pixels +
>>> +
>>> picture->format.i_y_offset * picture->p[0].i_pitch +
>>> +
>>> picture->format.i_x_offset * picture->p[0].i_pixel_pitch,
>>>                                                   
>>> picture->p[0].i_pitch);
>>>           if (hr != S_OK)
>>>               msg_Err(vd, "Failed to copy bitmap memory (hr = 
>>> 0x%x)!",
>>>
>>
>> This is incorrect. The last line in particular is going to write 
>> further
>> than the buffer allocated for display.
>
> Looking further into video_output modules (on Windows) it seems none
> of them are actually ready to do some proper cropping.

Visible width and height work fine for me (on X11). It is very likely 
that some other output plugins do not handle this properly.

However IIRC non-zero crop offsets from the input (decoder and/or demux 
or access_demux) does not work properly. I believe this is a limitation 
of the video output core: it effectively assumes that the input is only 
cropped to the bottom and/or right. Also most video filters ignore 
offsets, while a few of them probably need to care.

The video outputs should not need to care whether the top/left offset 
is non-zero because of user cropping or input cropping. Since user 
cropping works fine, input cropping should work fine just as well.

> Some could theoretically handle it internally, some just can't do it
> with hardware acceleration. In this case there should be a crop 
> filter
> inserted between the decoder and the video_output (or stream_output).

A crop filter is a possible optimization in the case where the visible 
dimensions do not change. But generally, the scaler already takes care 
of cropping just fine if the video output does not. XVideo is an example 
of video output that can scale but cannot crop (at least not without 
bleeding).

-- 
Rémi Denis-Courmont