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

[Steve Lhomme]

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.

- Direct2D uses ID2D1Bitmap_CopyFromMemory() for blitting which doesn't 
take in account the horizontal stride corresponding to the visible part 
of the image. Thus copying data where it shouldn't, resulting in green bars.

Direct2D supports cropping in Win7+.
https://msdn.microsoft.com/en-us/library/windows/desktop/hh706324%28v=vs.85%29.aspx

- Windows GDI uses BitBlt() and StretchBlt() which has no notion of 
stride/pitch. So no way to crop in there.

I'm not too familiar with the D3D and OpenGL textures but when setting 
crop values, it doesn't work properly. See the bleeding here:
http://imgur.com/a/8hdIJ#1

So it seems in general the code is not meant/ready to handle crop values 
on the planes coming from the decoders.

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

Opinions ?