[Bug 665525] New: Pad with probe won't forward flush events even though it's not blocking yet
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Sat Dec 3 17:13:20 PST 2011
https://bugzilla.gnome.org/show_bug.cgi?id=665525
GStreamer | gstreamer (core) | 0.11.x
Summary: Pad with probe won't forward flush events even though
it's not blocking yet
Classification: Platform
Product: GStreamer
Version: 0.11.x
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gstreamer (core)
AssignedTo: gstreamer-bugs at lists.freedesktop.org
ReportedBy: matej.knopp at gmail.com
QAContact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created an attachment (id=202734)
--> (https://bugzilla.gnome.org/attachment.cgi?id=202734)
Patch to forward flush events when the pad has blocking probe but is not yet
blocking.
The following code doesn't seem right
case GST_EVENT_FLUSH_START:
GST_PAD_SET_FLUSHING (pad);
if (G_UNLIKELY (GST_PAD_IS_BLOCKED (pad))) {
/* flush start will have set the FLUSHING flag and will then
* unlock all threads doing a GCond wait on the blocking pad. This
* will typically unblock the STREAMING thread blocked on a pad. */
GST_LOG_OBJECT (pad, "Pad is blocked, not forwarding flush-start, "
"doing block signal.");
GST_PAD_BLOCK_BROADCAST (pad);
goto flushed;
}
break;
GST_PAD_IS_BLOCKED (pad) is true even if pad is not blocking yet, so the
condition is signaled in vain. Changing the check to GST_PAD_IS_BLOCKING (pad)
fixes it
Same goes for FLUSH_STOP. Although I'm not sure how the pad could get blocked
while being flushed.
--
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