[Bug 748163] crop handling in gl plugins (gleffect, glimagesink, glshader, .....)
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Jul 7 01:14:14 PDT 2015
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.
More information about the gstreamer-bugs
mailing list