A420 is a four planar format similar to I420 but with an extra buffer
for alpha values.
A common use of the gl stack is for GPU format conversions using
shaders, in which case one can use glupload, glcolorconvert and
gldownload elements to upload their buffer to the GPU context, perform
the conversion on the GPU itself and then retrieve the data to CPU
context.
A420 was not supported. This patch adds said support mainly by adding
the corresponding shader to perform the conversion and updating the
supported caps.
Both A420->RGBA and RGBA->A420 conversions are supported.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1153>
While so far it worked, we are about to introduce a format that break this
assuming. We have a format which consist of NV12 with alpha, and this format
does not have a direct mapping of the component against their plane indexes.
Fix this by using gst_video_format_info_component() introduced in 1.18 for
this purpose.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1151>
e.g. if running a dual wgl/egl built library, then egl will always
succeed in creating the GstGLContext because almost anything could
support egl, as long as eglGetDisplay() works.
wgl, however has a check for the correct display type so should move
earlier in the tried list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1154>
New API:
- gst_gl_context_get_config()
- gst_gl_context_request_config()
A GL context configuration is a GstStructure that has some well-known
names for common values that can also be extended in platform-specific
ways if necessary.
Wrapped OpenGL contexts may be able to retrieve the GL context
configuration depending on the platform. If that information is
available, GstGLContext will attempt to create an context that matches
the shared OpenGL context config unless gst_gl_context_request_config()
has been called.
A new environment variable 'GST_GL_CONFIG' will be read to influence the
configuration chosen. The environment variable will only be used as a
fallback if gst_gl_context_request_config() has not been called.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/809>
If the `render_rect` for a dispmanx display is set after calling
`window_resize` the resize defaults to the dp_width and dp_height to
determine the location of the render rectangle instead of the correct
dimensions that should be set on the window_egl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1056>
When the gstglimagesink is started with the option `glimagesink
render-rectangle="<0,0,1920,1080>"`, the pipeline reaches a deadlock.
The reason the deadlock occurs is that the
`gst_gl_window_set_render_rectangle` takes locks on the window, in
addition it calls `window_class->set_render_rectangle(...)` which
executes the `_on_resize` function. Since the `_on_resize` function also
takes locks on the window the deadlock is achieved.
By scheduling the adjustment of the render rectangle through an async
message for `gst_gl_window_dispmanx_set_render_rectangle`, the actual
resize happens in another context and therefore doesn't suffers from the
lock taken in `gst_gl_window_set_render_rectangle`.
This solution follows the same approach as gl/wayland. The problem was
introduced by b887db1. For the full discussion check #849.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1030>
These parameters are incorrectly regarded as mutable in G-IR making them
"incompatible" with languages that are explicit about mutability like
Rust. In order to clean up the code and expected API there, update the
signatures here, right at the source (instead of overriding them in
Gir.toml and hoping for the best).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1005>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/681
added a layoutSubViews, which never gets called, because it should have been
called layoutSubviews (non-capital "v"). However after fixing that, it still
doesn't work correctly, because window_width/height values are immediately
updated and then draw_cb will never trigger the resize path, because the
values are already up to date.
Update the values inside the resize path again instead, so the check for
entering the resize path is logically always correct.
This makes the layoutSubviews unnecessary, as it only updated the internal
size values prematurely, so it is deleted instead of method naming fixed.
These changes were originally done to avoid accessing UIKit objects on the
main thread, but no additional accesses are added here, only internal
private variable assignments under the same draw_lock, so there should be
no threading issues reintroduced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/945>
A CGSize contains CGFloat values (a typedef to double or float), which means
that the values aren't equal, despite it being equal after they are cast to
int by assigning them to window_height/width private members. This leads to
excessive gst_gl_window_resize calls on each frame, at least if the CGFloat
value has a .5 decimal value, e.g. 103.5.
Fix it by storing them as CGFloat instead of gint.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/945>
GLSLstage creates the glShader using glCreateShader, but never calls
glDeleteShader if the glShader is not used anymore. This forces the GL
library to keep the compiled shader around, because it might be used in
the future. Therefore, the glShader is leaked whenever a GLSLStage is
destroyed.
Fix the leak by deleting the glShader when finishing the GLSLStage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/886>
`gst_gl_memory_read_pixels` reads pixels from `GLMemory` into the
pointer, effectively writing to it. This is opposite from
`gst_gl_memory_texsubimage` which reads texture data from `read_pointer`
into `GLMemory`.
Both cases are clarified by changing `read_pointer` to `write_pointer`,
and explaining what `gst_gl_memory_texsubimage` does in addition to
referring back to `gst_gl_memory_read_pixels`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/806>
5 seconds might not be enough value for timeout in case an application
is running on a device with very limited computing power.
Note that ANGLE uses 10 seconds timeout value. So even if a timeout
happens here, it's also ANGLE's timeout condition as well
(meaning that bad things will happen either way)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/769>
All UI elements will follow Single-Threaded Apartments (STA) model.
As a result, we should access them from dedicated UI thread.
Due to the nature of the threading model, ANGLE will wait the UI
thread while closing internal window/swapchain objects.
A problem here is that when destroying GstGLWindow from the UI thread,
it will wait GstGLContext's internal thread. Meanwhile, the GstGLContext's
internal thread will be blocked because ANGLE wants to access the UI thread.
That will cause a deadlock or exceptions.
In short, application should not try to call
gst_element_set_state(pipeline, GST_STATE_NULL) from a UI thread.
That's a limitation of current implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/745>
