[Bug 715192] STREAM_LOCK is locked excessively during finish_frame() function of GstVideoDecoder

[GStreamer (bugzilla.gnome.org)]

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

Alexey Chernov <4ernov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED

--- Comment #3 from Alexey Chernov <4ernov at gmail.com> 2013-11-25 20:17:14 UTC ---
Thanks for detailed information, Nicolas.
Yes, I have a use-case for it: a multithreaded decoder based on GstVideoDecoder
with three threads: one input thread which rotates handle_frame(), one thread
which rotates hardware decoder itself and an output thread which does
finish_frame(). All threads are connected using a queue, a mutex and wait
condition (input-decoder and decoder-output). Some variation of this model is
used in gst-omx decoder. So, everything works fine until there's no external
queue after decoder element or this queue is full. In such case finish_frame()
is blocked for fair amount of time by gst_pad_push(), so is STREAM_LOCK. Output
thread is blocked by finish_frame() and it's normal, but the problem is that
there's also tension between output thread and input thread. As STREAM_LOCK
mutex is locked most part of time and has no wait condition there's no
guarantee that input thread would see it released when scheduler would make it
active. Actually it wouldn't most of times, so handle_frame() can't provide any
input frames for decoder, decoder processes all the frames in its input queue
and fall asleep. Only after that output thread starts to wait on the wait
condition of output queue and stops to occupy STREAM_LOCK too often. Input
thread receives a chance to provide some frames, decoder starts to work, in
some time it fills out external queue if there's one and the problem repeats.
It looks like oscillation.

I see that STREAM_LOCK is quite special instrument by its nature, but it seems
that unlocking it for gst_pad_push() can be very helpful for the cases as
mentioned above. You're right that it requires more accurate way to do output
routines, but this code is usually quite serialized and all such calls are
usually in the same thread.

-- 
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.