[Bug 748163] crop handling in gl plugins (gleffect, glimagesink, glshader, .....)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748163

Matthew Waters <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ystreet00 at gmail.com

--- Comment #1 from Matthew Waters <ystreet00 at gmail.com> ---
(In reply to Jian Li from comment #0)
> Is there a plan to support video cropping in gl plugins? 
> Although this can be done when you uploading the pixel data into texture,
> there is still cases that you can use some extension to bind a buffer to the
> texture, such as eglimage, dma-bufer or some private extensions. If decoder
> needs padding or alignment when output video into this buffer, the gl
> plugins need to handle it correctly.

GstVideoAlignment is more suited to any data alignment constraints which
GLMemory already supports in master.

> I tried to support it, but have below question:
> 
> 1. How to get the video buffer width and height?
> 
> I can get crop info from GstVideoCropMeta, but how can I get the buffer
> width and height? We can get real video width/height from GstVideoInfo, but
> can't get the buffer widht/height after padding/aligned. One way I found is
> like below for I420 and NV12 video: 
> 
> videometa = gst_buffer_get_video_meta (buf);
> bufw = videometa->stride[0];
> bufh = videometa->offset[1] / bufw;
> 
> Is there a better way to get this info?

Currently, no.  IIRC the display video width/height is in the caps/video meta. 
The GstVideoCropMeta instead is subtractive of the data size.  The data width
for each plane is equivalent to the stride.  The plane data height is a little
more tricky to compute directly.  In practice though one only needs the plane
display height of the frame.  With the crop meta, one is given a crop rectangle
defined by a point and two lengths and so the data height isn't needed.  One
just uses crop->height rows of pixels.

In the GL case, caps size == data size, there's no padding/alignment for the
textures within GL.  It's only when the textures are in system memory that
padding/alignment is taken into account.

> 2. Supporting crop handling only need to recalculate the texture coordinate,
> but I found every gl plugin has their own vertices definition, this means I
> need to modify everywhere to support this.
> Is there a plan to make it into a common module?

My plan for this was to wrap VAO's in a new object and have a new memory type
based off glbasebuffer to contain the required vertex data.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.