Reset redraw_pending at display disconnection, so we can re-connect
later from a clean state (avoid endless buffer drops).
Add a log to inform of dropped buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=775791
wldisplay.c:179:15: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare]
if (shm_fmt < 0)
~~~~~~~ ^ ~
gstsegmentation.cpp:419:40: error: implicit conversion from 'int' to 'char' changes value from 255 to -1 [-Werror,-Wconstant-conversion]
filter->cvFG->imageData[j] = 255;
~ ^~~
https://bugzilla.gnome.org/show_bug.cgi?id=775112
Support the wayland zwp_linux_dmabuf_unstable_v1 protocol.
SHM formats and DMABuf formats are exposed differently in caps: the
DMABuf formats are flagged with GST_CAPS_FEATURE_MEMORY_DMABUF.
No buffer pool is proposed for DMABuf buffers, it is the upstream
element responsibility to provide with such buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=711155
This is specific to when the waylandsink is not being embedded. In
this patch we pass the render lock to the window so it can safely
call gst_wl_window_set_render_rectangle() with the new size.
https://bugzilla.gnome.org/show_bug.cgi?id=722343
We already take the render lock from the wlqueue thread in some other
place which indicates that there is no use of this atomic instead of
a proper locking mechanism.
When we don't have a viewporter (scaling support), we can't use the
1x1 scaleup image trick. Instead, we need to allocate a buffer with
the same size as the area that need to have black background.
This add support for non-standard strides to be used. Note that
some extra work is needed for multi-plane format which may have
a different GstMemory object per plane. This is not currently a
problem since SHM interface is limited to 1 memory.
The buffer pool API does not allow multiple of owner. This otherwise
lead to error when renegotiation take place. Aso consider the
allocation query "need_pool" boolean.
This makes the viewporter interface optional. The end result is
obviously far from optimal, though it greatly helps testing on older
compostitors or gnome-wayland. We can make it strictly needed later when
this new interface get widely adopted.
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
Waylandsink needs exception code in gst_wayland_sink_set_window_handle().
After making sink->window, User can call
gst_wayland_sink_set_window_handle(). It is the user's fault, but
Waylandsink needs to handle the exception, if not then sink->window is
changed and rendering fails.
https://bugzilla.gnome.org/show_bug.cgi?id=747482
Waylandsink needs exception code in gst_wayland_sink_set_context(). After
calling gst_wayland_sink_set_context(), below code is set.
GST_ELEMENT_CLASS (parent_class)->set_context (element, context); but, If
user can call onemore. It is user's fault. but waylandsink need to
exception.
https://bugzilla.gnome.org/show_bug.cgi?id=747482
This wl_display proxy is temporary only until waylandsink goes NULL,
at which point the connection to the display is disposed. Unfortunately,
if this is advertised as a GstContext, playbin will cache it and re-feed
it to the sink when it goes PLAYING again, but the wl_display pointer
will at that point be invalid and cause a crash.
Another solution to the problem would be to also cache the GstWlDisplay
object inside the GstContext, which would automatically ref-count
the display connection, but I see no reason in doing that at the moment,
as there are no known users of this GstContext outside waylandsink.
It's probably better to avoid chasing hidden refcounts.
https://bugzilla.gnome.org/show_bug.cgi?id=756567
Using mkstemp without setting the permission mask is potentially harmful.
POSIX specification of mkstemp() does not say anything about file modes, so we
need to make sure its file mode creation mask is set appropriately before
calling it.
Do not try to render a buffer that is already being rendered.
This happens typically during the initial rendering stage as the first
buffer is rendered twice: first by preroll(), then by render().
This commit avoids this assertion failure:
CRITICAL: gst_wayland_compositor_acquire_buffer: assertion
'meta->used_by_compositor == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=738069
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
If waylandsink is the owner of the display then it is in charge
of catching input events on the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=733682
Signed-off-by: Tifaine Inguere <tifaine.inguere@st.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
There are two cases covered here:
1) The GstWlDisplay forces the release of the last buffer and the pool
gets destroyed in this context, which means it unregisters all the
other buffers from the GstWlDisplay as well and the display->buffers
hash table gets corrupted because it is iterating.
2) The pool and its buffers get destroyed concurrently from another
thread while GstWlDisplay is finalizing and many things get corrupted.
The main reason behind this is that when the video caps change and the video
subsurface needs to resize and change position, the wl_subsurface.set_position
call needs a commit in its parent in order to take effect. Previously,
the parent was the application's surface, over which there is no control.
Now, the parent is inside the sink, so we can commit it and change size smoothly.
As a side effect, this also allows the sink to draw its black borders on
its own, without the need for the application to do that. And another side
effect is that this can now allow resizing the sink when it is in top-level
mode and have it respect the aspect ratio.
Because we no longer have a custom buffer pool that holds a reference
to the display, there is no way for a cyclic reference to happen like
before, so we no longer need to explicitly call a function from the
display to release the wl_buffers.
However, the general mechanism of registering buffers to the display
and forcibly releasing them when the display is destroyed is still
needed to avoid potential memory leaks. The comment in wlbuffer.c
is updated to reflect the current situation.
