GNOME Bugzilla – Bug 701650
v4l2: make sure the element is not deleted before the pool
Last modified: 2013-06-07 18:08:49 UTC
Created attachment 246082 [details] [review] patch The pool accesses data from the v4l2object so it must exist at least as long as the pool. Refcount the element which controls the object live-time.
Note that this creates a refcount circle. v4l2object and pool own a reference of each other. Which will mean that you will leak both. The alternative is a (see xvimagesink) object to hold the v4l2 context, which is owned by both the sink and the buffer pool.
Ther is no refcount cycle. v4l2object releases the ref to the pool in gst_v4l2_object_stop(). When the last buffer returns to the pool, pool_stop() is called and the the pool is deleted. Then the element and object are deleted (unless there are other refs to the element).
Indeed, and that happens even before finalizing the sink/src element. Sorry commit a1c34b540735a7a23b15cdb77ecba1b28adb93ee Author: Michael Olbrich <m.olbrich@pengutronix.de> Date: Wed Jun 5 16:32:30 2013 +0200 v4l2: make sure the element is not deleted before the pool The pool accesses data from the v4l2object so it must exist at least as long as the pool. Refcount the element which controls the object live-time. https://bugzilla.gnome.org/show_bug.cgi?id=701650