[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