[Bug 742074] v4l2videodec: leaks filedescriptors

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Jan 7 09:40:51 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=742074
  GStreamer | gst-plugins-good | git

Nicolas Dufresne (stormer) <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk
     Ever Confirmed|0                           |1

--- Comment #1 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2015-01-07 17:40:44 UTC ---
After some research, what I like of releasing the output buffers from
flush_start() is that it means it works well when the pool is used from the
outside of the element. This might be particularly handy for being able to
implement re-negotiation.

Now, the problem is that doing so means we play on buffers array while some
qbuf/dqbuf might be being called. Acquire/Release was originally lockless by
design, hence would only change the array on flush_stop(), which happens before
threads start doing parrallel access.

I'm saying was, since we introduced a lock to workaround a bug in videobuf2
when the queue is empty. We also do an iotcl, which could possibly be a
pre-emption point. So all this being considered, we should maybe simply buffer
array with a lock. It should be light locking so we can still run
acquire/release in parallel and minimise the risk of deadlock.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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