mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-26 18:20:44 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/ext/wayland/wlbuffer.c

236 lines
8.5 KiB
C
Raw Normal View History

waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
/* GStreamer Wayland video sink
*
* Copyright (C) 2014 Collabora Ltd.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library; if not, write to the Free
* Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301 USA.
*/
/* GstWlBuffer wraps wl_buffer and provides a mechanism for preventing
* buffers from being re-used while the compositor is using them. This
* is achieved by adding a reference to the GstBuffer as soon as its
* associated wl_buffer is sent to the compositor and by removing this
* reference as soon as the compositor sends a wl_buffer::release message.
*
* This mechanism is a bit complicated, though, because it adds cyclic
* references that can be dangerous. The reference cycles looks like:
*
* ----------------
waylandsink: remove the ugly gst_wl_display_stop() now that this mechanism is not needed anymore 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.
2014-06-23 14:27:01 +00:00
* | GstWlDisplay | ---------------------------->
* ---------------- |
* |
* V
* ----------------- ------------- ---------------
* | GstBufferPool | --> | GstBuffer | ==> | GstWlBuffer |
* | | <-- | | <-- | |
* ----------------- ------------- ---------------
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
*
* A GstBufferPool normally holds references to its GstBuffers and each buffer
* holds a reference to a GstWlBuffer (saved in the GstMiniObject qdata).
* When a GstBuffer is in use, it holds a reference back to the pool and the
* pool doesn't hold a reference to the GstBuffer. When the GstBuffer is unrefed
* externally, it returns back to the pool and the pool holds again a reference
* to the buffer.
*
* Now when the compositor is using a buffer, the GstWlBuffer also holds a ref
* to the GstBuffer, which prevents it from returning to the pool. When the
* last GstWlBuffer receives a release event and unrefs the last GstBuffer,
* the GstBufferPool will be able to stop and if no-one is holding a strong
waylandsink: remove the ugly gst_wl_display_stop() now that this mechanism is not needed anymore 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.
2014-06-23 14:27:01 +00:00
* ref to it, it will be destroyed. This will destroy the pool's GstBuffers and
* also the GstWlBuffers. This will all happen in the same context of the last
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
* gst_buffer_unref, which will be called from the buffer_release() callback.
*
waylandsink: remove the ugly gst_wl_display_stop() now that this mechanism is not needed anymore 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.
2014-06-23 14:27:01 +00:00
* The problem here lies in the fact that buffer_release() will be called
* from the event loop thread of GstWlDisplay, so it's as if the display
* holds a reference to the GstWlBuffer, but without having an actual reference.
* When we kill the display, there is no way for the GstWlBuffer, the associated
* GstBuffer and the GstBufferPool to get destroyed, so we are going to leak a
* fair ammount of memory.
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
*
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
* Normally, this rarely happens, because the compositor releases buffers
* almost immediately and when waylandsink stops, they are already released.
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
*
* However, we want to be absolutely certain, so a solution is introduced
waylandsink: remove the ugly gst_wl_display_stop() now that this mechanism is not needed anymore 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.
2014-06-23 14:27:01 +00:00
* by registering all the GstWlBuffers with the display and explicitly
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
* releasing all the buffer references as soon as the display is destroyed.
*
* When the GstWlDisplay is finalized, it takes a reference to all the
* registered GstWlBuffers and then calls gst_wl_buffer_force_release_and_unref,
* which releases the potential reference to the GstBuffer, destroys the
* underlying wl_buffer and removes the reference that GstWlDisplay is holding.
* At that point, either the GstBuffer is alive somewhere and still holds a ref
* to the GstWlBuffer, which it will release when it gets destroyed, or the
* GstBuffer was destroyed in the meantime and the GstWlBuffer gets destroyed
* as soon as we remove the reference that GstWlDisplay holds.
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
*/
#include "wlbuffer.h"
GST_DEBUG_CATEGORY_EXTERN (gstwayland_debug);
#define GST_CAT_DEFAULT gstwayland_debug
G_DEFINE_TYPE (GstWlBuffer, gst_wl_buffer, G_TYPE_OBJECT);
static G_DEFINE_QUARK (GstWlBufferQDataQuark, gst_wl_buffer_qdata);
static void
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
gst_wl_buffer_dispose (GObject * gobject)
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
{
GstWlBuffer *self = GST_WL_BUFFER (gobject);
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
GST_TRACE_OBJECT (self, "dispose");
/* if the display is shutting down and we are trying to dipose
* the GstWlBuffer from another thread, unregister_buffer() will
* block and in the end the display will increase the refcount
* of this GstWlBuffer, so it will not be finalized */
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
if (self->display)
gst_wl_display_unregister_buffer (self->display, self);
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
G_OBJECT_CLASS (gst_wl_buffer_parent_class)->dispose (gobject);
}
static void
gst_wl_buffer_finalize (GObject * gobject)
{
GstWlBuffer *self = GST_WL_BUFFER (gobject);
GST_TRACE_OBJECT (self, "finalize");
if (self->wlbuffer)
wl_buffer_destroy (self->wlbuffer);
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
G_OBJECT_CLASS (gst_wl_buffer_parent_class)->finalize (gobject);
}
static void
gst_wl_buffer_class_init (GstWlBufferClass * klass)
{
GObjectClass *object_class = (GObjectClass *) klass;
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
object_class->dispose = gst_wl_buffer_dispose;
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
object_class->finalize = gst_wl_buffer_finalize;
}
static void
gst_wl_buffer_init (GstWlBuffer * self)
{
}
static void
buffer_release (void *data, struct wl_buffer *wl_buffer)
{
GstWlBuffer *self = data;
GST_LOG_OBJECT (self, "wl_buffer::release (GstBuffer: %p)", self->gstbuffer);
self->used_by_compositor = FALSE;
/* unref should be last, because it may end up destroying the GstWlBuffer */
gst_buffer_unref (self->gstbuffer);
}
static const struct wl_buffer_listener buffer_listener = {
buffer_release
};
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
static void
gstbuffer_disposed (GstWlBuffer * self)
{
g_assert (!self->used_by_compositor);
self->gstbuffer = NULL;
GST_TRACE_OBJECT (self, "owning GstBuffer was finalized");
/* this will normally destroy the GstWlBuffer, unless the display is
* finalizing and it has taken an additional reference to it */
g_object_unref (self);
}
waylandsink: stack the video subsurface into another subsurface that covers the whole render rectangle 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.
2014-07-01 08:43:20 +00:00
GstWlBuffer *
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
gst_buffer_add_wl_buffer (GstBuffer * gstbuffer, struct wl_buffer *wlbuffer,
GstWlDisplay * display)
{
GstWlBuffer *self;
self = g_object_new (GST_TYPE_WL_BUFFER, NULL);
self->gstbuffer = gstbuffer;
self->wlbuffer = wlbuffer;
self->display = display;
gst_wl_display_register_buffer (self->display, self);
wl_buffer_add_listener (self->wlbuffer, &buffer_listener, self);
gst_mini_object_set_qdata ((GstMiniObject *) gstbuffer,
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
gst_wl_buffer_qdata_quark (), self, (GDestroyNotify) gstbuffer_disposed);
waylandsink: stack the video subsurface into another subsurface that covers the whole render rectangle 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.
2014-07-01 08:43:20 +00:00
return self;
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
}
GstWlBuffer *
gst_buffer_get_wl_buffer (GstBuffer * gstbuffer)
{
return gst_mini_object_get_qdata ((GstMiniObject *) gstbuffer,
gst_wl_buffer_qdata_quark ());
}
void
gst_wl_buffer_force_release_and_unref (GstWlBuffer * self)
{
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
/* Force a buffer release.
* At this point, the GstWlDisplay has killed its event loop,
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
* so we don't need to worry about buffer_release() being called
* at the same time from the event loop thread */
if (self->used_by_compositor) {
GST_DEBUG_OBJECT (self, "forcing wl_buffer::release (GstBuffer: %p)",
self->gstbuffer);
self->used_by_compositor = FALSE;
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
gst_buffer_unref (self->gstbuffer);
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
}
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
/* Finalize this GstWlBuffer early.
* This method has been called as a result of the display shutting down,
* so we need to stop using any wayland resources and disconnect from
* the display. The GstWlBuffer stays alive, though, to avoid race
* conditions with the GstBuffer being destroyed from another thread.
* The last reference is either owned by the GstBuffer or by us and
* it will be released at the end of this function. */
GST_TRACE_OBJECT (self, "finalizing early");
wl_buffer_destroy (self->wlbuffer);
self->wlbuffer = NULL;
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
self->display = NULL;
waylandsink: take into account the case where a pool may be destroyed together with GstWlDisplay 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.
2014-07-02 10:29:55 +00:00
/* remove the reference that the caller (GstWlDisplay) owns */
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
g_object_unref (self);
}
void
waylandsink: stack the video subsurface into another subsurface that covers the whole render rectangle 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.
2014-07-01 08:43:20 +00:00
gst_wl_buffer_attach (GstWlBuffer * self, struct wl_surface *surface)
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
{
wayland/wlbuffer: just return if used_by_compositor is true when attach When buffer is used by compositor, we don't need attach it and hold one more reference. Just check used_by_compositor, just return if it is true. Assert error log is not need, this is normal behavior.
2018-10-18 05:35:04 +00:00
if (self->used_by_compositor) {
GST_DEBUG_OBJECT (self, "buffer used by compositor %p", self->gstbuffer);
return;
}
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
waylandsink: stack the video subsurface into another subsurface that covers the whole render rectangle 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.
2014-07-01 08:43:20 +00:00
wl_surface_attach (surface, self->wlbuffer, 0, 0);
waylandsink: rework the mechanism for keeping buffers out of the pool until wl_buffer::release This also removes the GstWlMeta and adds a wrapper class for wl_buffer which is saved in the GstBuffer qdata instead of being a GstMeta. The motivation behind this is mainly to allow attaching wl_buffers on GstBuffers that have not been allocated inside the GstWaylandBufferPool, so that if for example an upstream element is sending us a buffer from a different pool, which however does not need to be copied to a buffer from our pool because it may be a hardware buffer (hello dmabuf!), we can create a wl_buffer directly from it and first, attach it on it so that we don't have to re-create a wl_buffer every time the same GstBuffer arrives and second, force the whole mechanism for keeping the buffer out of the pool until there is a wl_buffer::release on that foreign GstBuffer.
2014-06-20 11:47:57 +00:00
/* Add a reference to the buffer. This represents the fact that
* the compositor is using the buffer and it should not return
* back to the pool and be re-used until the compositor releases it. */
gst_buffer_ref (self->gstbuffer);
self->used_by_compositor = TRUE;
}
Reference in a new issue Copy permalink