[Bug 720805] New: pad: stop running tasks before deactivation requests?

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=720805
  GStreamer | gstreamer (core) | 1.2.1

           Summary: pad: stop running tasks before deactivation requests?
    Classification: Platform
           Product: GStreamer
           Version: 1.2.1
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: gb.devel at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Hi, bug #720584 exposed a bug that I believe could rather lay in GstPad. We
have determined that when the user hits Ctrl+C on the terminal, we are changing
states from PAUSED to READY. This causes the GstVideoDecoder's parent
change_state hook to be called, before subclasses have a chance to stop()
anything. This subsequently causes the pad to get deactivated.

In the chain of events, this causes the pad deactivation logic to acquire the
stream lock. If we have task running around, the stream lock is never released
until that task is paused.

Ways to fix this issue:

1. Fix all GstVideoDecoder-based elements that use a srcpad task to make sure
that task gets paused when we change from PAUSED to READY. This either means
(i) hook up GstElement::change_state() hook and stop running tasks in there, or
(ii) track whether the pad is actually still alive in the task callback
function and pause itself otherwise.

2. Find a way in GstVideoDecoder to notify subclasses earlier that we are going
to change states and that stop() hook may need to be called before
change_state() is called.

3. Make sure GstPad stops any running task itself when it is getting
deactivated.

I'd much prefer solution (3) as, in the general case, it doesn't seem
completely right to me to still have running tasks around after a pad got
deactivated anyway. Or am I failing to see the use-case for that? Thanks.

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