[vlc-devel] [PATCH] respect the x,y offset in Direct2D
robux4 at gmail.com
Thu Mar 5 15:48:57 CET 2015
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
>> 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.p_pixels,
>> + picture->p.p_pixels +
>> picture->format.i_y_offset * picture->p.i_pitch +
>> picture->format.i_x_offset * picture->p.i_pixel_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+.
- 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:
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).
More information about the vlc-devel