After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796619 - parsebin: forwarding sticky events causes issues with validate
parsebin: forwarding sticky events causes issues with validate
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-18 13:11 UTC by Edward Hervey
Modified: 2018-11-03 12:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2018-06-18 13:11:47 UTC
in the parsebin blocking pad probe handler, we forward sticky events ourselves and returning GST_PAD_PROBE_HANDLED.

The problem is that if there were other non-blocking event probes on that pad or an upstream pad ... it will never be called.

The reason for why is so that when the ghostpad is exposed, it has all sticky events on it.

We need to figure out another way to handle those events at the parsebin level.
Comment 1 Jan Schmidt 2018-06-20 12:40:57 UTC
I don't see an obvious answer to the problem - we want all events to already be there when the pad appears - which is before the validate probe gets added?
Comment 2 Edward Hervey 2018-06-20 14:22:44 UTC
(In reply to Jan Schmidt from comment #1)
> I don't see an obvious answer to the problem - we want all events to already
> be there when the pad appears - which is before the validate probe gets
> added?

It's more subtle than that.

1) Demuxer creates a pad and sends events on it before adding it (say SEGMENT)
2) Demuxer adds pad
3) validate adds a non-blocking event probe on that pad
4) parsebin adds a blocking event probe on that pad
5) demuxer pushes something
6) pad code checks for pending sticky events and for each:
 6.1) It first calls the blocking variants of probes
   6.2) the validate one doesn't match
   6.3) the parsebin one matches and it returns GST_PAD_PROBE_HANDLED
 6.4 ... because one probe returns HANDLED the non-blocking pad probes aren't called
Comment 3 GStreamer system administrator 2018-11-03 12:08:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/462.