[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

Nicolas Dufresne <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #2 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2013-11-25 19:58:09 UTC ---
That change seems odd to me considering what a stream lock is. Is there any
use-case, sample code that demonstrate an issue, or real contention here ?

Fyi, the stream lock(s) is what protects the stream, there is one on each pad,
and few element also have one. They are normally kept locked as long as the pad
or the element is streaming. This is a very specialized lock, which can be
unlocked by certain event, like flush-start. It's not intended for general
protection, though we need to be careful of the locking order, the reason we
cannot ignore it.

Finally, by unlocking it before pushing, you open a gap where another push
could hypothetically happen (depend on the implementation on top of the
baseclass), causing buffer or event miss-ordering. It would be a very hard
problem to track.

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