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 331727 - make probes and Ghostpads more elegant
make probes and Ghostpads more elegant
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other All
: Normal enhancement
: 0.10.9
Assigned To: Wim Taymans
GStreamer Maintainers
: 325259 (view as bug list)
Depends on:
Blocks: 341029
 
 
Reported: 2006-02-19 00:15 UTC by Julien MOUTTE
Modified: 2006-07-11 17:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch to make probes on the target pad if it's a ghostpad (2.44 KB, patch)
2006-02-19 00:22 UTC, Julien MOUTTE
none Details | Review
Apply the same fix gst_pad_set_blocked (3.16 KB, patch)
2006-02-19 16:59 UTC, Julien MOUTTE
none Details | Review
Same patch but without leaking the target pad refcount (5.84 KB, patch)
2006-02-19 22:25 UTC, Julien MOUTTE
committed Details | Review
multi-ghostpad fix for ghostpad (2.41 KB, patch)
2006-05-05 16:07 UTC, Edward Hervey
none Details | Review
updated version, handles gst_pad_set_blocked_async() too (3.02 KB, patch)
2006-05-05 16:14 UTC, Edward Hervey
none Details | Review
Updated version, with a unit test to show the fix (6.09 KB, patch)
2006-05-05 17:33 UTC, Edward Hervey
none Details | Review

Description Julien MOUTTE 2006-02-19 00:15:58 UTC
Please describe the problem:
Ghostpads are not receiving data flow so they will never trigger an event or a
data probe. That's very annoying for playbin and the streaminfo probes.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Julien MOUTTE 2006-02-19 00:22:21 UTC
Created attachment 59674 [details] [review]
Proposed patch to make probes on the target pad if it's a ghostpad
Comment 2 Wim Taymans 2006-02-19 12:36:25 UTC
*** Bug 325259 has been marked as a duplicate of this bug. ***
Comment 3 Wim Taymans 2006-02-19 12:37:35 UTC
the ghostpad should behave like any other pad so the fix should be something local to the ghostpads. I might have a clue what's wrong here.
Comment 4 Julien MOUTTE 2006-02-19 16:59:10 UTC
Created attachment 59716 [details] [review]
Apply the same fix gst_pad_set_blocked
Comment 5 Julien MOUTTE 2006-02-19 22:25:22 UTC
Created attachment 59740 [details] [review]
Same patch but without leaking the target pad refcount
Comment 6 Julien MOUTTE 2006-02-20 15:07:42 UTC
Fixed in CVS HEAD
Comment 7 Wim Taymans 2006-02-28 11:46:57 UTC
reopening as we must find something that is more transparent.

I'm thinking about a notification when a probe/block is installed.
Comment 8 Edward Hervey 2006-05-05 15:57:18 UTC
It doesn't work if the target of the ghostpad is also a ghostpad.
Comment 9 Edward Hervey 2006-05-05 16:07:52 UTC
Created attachment 64873 [details] [review]
multi-ghostpad fix for ghostpad

This is the proposed patch for gst_pad_[add|remove]_*_probe().

Instead of assuming that there can only be ghostpads of real pad, it will recursively got up the targets until it reaches a non-ghostpad.
Comment 10 Edward Hervey 2006-05-05 16:14:15 UTC
Created attachment 64875 [details] [review]
updated version, handles gst_pad_set_blocked_async() too

We also need to handle the case for gst_pad_set_blocked_async().
Comment 11 Edward Hervey 2006-05-05 17:33:03 UTC
Created attachment 64877 [details] [review]
Updated version, with a unit test to show the fix

Better with a unit test.
Comment 12 Andy Wingo 2006-05-08 08:59:53 UTC
The patch is incorrect wrt refcounts.

  while (GST_IS_GHOST_PAD (pad)) {
    if (was_ghost)
      gst_object_unref (pad);
    pad = gst_ghost_pad_get_target (GST_GHOST_PAD (pad));

You only have one reference on pad in the was_ghost==TRUE case, but you use its value after dropping your reference. You would need to make a temp variable and unref it after the get_target.

However this whole idea of including gstghostpad.h from within gstpad.c is incorrect. GstPad should supply an interface general enough that gstghostpad can implement this functionality on its own, without having to have gstpad.c explicitly call out to it.
Comment 13 Edward Hervey 2006-05-08 14:28:56 UTC
I created a new bug for the probe on ghostpad of ghostpad issue : 341029.

Marking this bug as a blocker of that one.
Comment 14 Edward Hervey 2006-07-11 17:05:55 UTC
2006-07-11  Edward Hervey  <edward@fluendo.com>

        * gst/gstbin.c: (activate_pads),
        (iterator_activate_fold_with_resync), (gst_bin_src_pads_activate),
        (gst_bin_change_state_func):
        (de)activate src pads before calling state_change on the childs.
        This is to avoid the case where a src ghostpad is blocked (holding the
        stream lock), which would block the deactivation of the ghostpad's
        target pad.
        * gst/gstghostpad.c: (gst_proxy_pad_do_query_type),
        (gst_proxy_pad_do_event), (gst_proxy_pad_do_query),
        (gst_proxy_pad_do_internal_link), (gst_proxy_pad_do_bufferalloc),
        (gst_proxy_pad_do_chain), (gst_proxy_pad_do_getrange),
        (gst_proxy_pad_do_checkgetrange), (gst_proxy_pad_do_getcaps),
        (gst_proxy_pad_do_acceptcaps), (gst_proxy_pad_do_fixatecaps),
        (gst_proxy_pad_do_setcaps), (gst_proxy_pad_set_target_unlocked),
        (gst_proxy_pad_set_target), (gst_proxy_pad_get_internal),
        (gst_proxy_pad_dispose), (gst_proxy_pad_init),
        (gst_ghost_pad_parent_set), (gst_ghost_pad_parent_unset),
        (gst_ghost_pad_class_init),
        (gst_ghost_pad_internal_do_activate_push),
        (gst_ghost_pad_internal_do_activate_pull),
        (gst_ghost_pad_do_activate_push), (gst_ghost_pad_do_activate_pull),
        (gst_ghost_pad_do_link), (gst_ghost_pad_do_unlink),
        (gst_ghost_pad_dispose), (gst_ghost_pad_new_no_target),
        (gst_ghost_pad_new), (gst_ghost_pad_set_target):
        GhostPads now create their internal GstProxyPad at creation (and not
        when they're linked, as it was being done previously).
        The internal and target pads are linked straight away.
        The data will also travel through the other pad in order to make
        pad blocking and probes non-hackish (the probe/block now really happens
        on the GhostPad and not on the target).
        * gst/gstpad.c: (gst_pad_set_blocked_async),
        (gst_pad_link_prepare), (gst_pad_push_event):
        Remove previous ghostpad cruft.
        * gst/gstutils.c: (gst_pad_add_data_probe),
        (gst_pad_add_event_probe), (gst_pad_add_buffer_probe),
        (gst_pad_remove_data_probe), (gst_pad_remove_event_probe),
        (gst_pad_remove_buffer_probe):
        Remove previous ghost pad cruft.
        Added more detailed debug statements.
        * tests/check/gst/gstghostpad.c: (GST_START_TEST):
        Fix the testsuite for refcounting changes.
        The comments about who has references were correct, but the refcount
        being checked wasn't the same (!?!).