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 761913 - ghostpad: Do nothing in _internal_activate_push_default
ghostpad: Do nothing in _internal_activate_push_default
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-02-12 10:26 UTC by Håvard Graff (hgr)
Modified: 2016-02-17 10:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.56 KB, patch)
2016-02-12 10:26 UTC, Håvard Graff (hgr)
committed Details | Review
ghostpad tests (2.58 KB, patch)
2016-02-17 10:08 UTC, Håvard Graff (hgr)
committed Details | Review

Description Håvard Graff (hgr) 2016-02-12 10:26:15 UTC
Created attachment 320950 [details] [review]
patch

When calling gst_pad_activate_mode() on a ghostpad
gst_ghost_pad_activate_push_default() will be called. This will call
gst_pad_activate_mode() on the proxypad (which is internal of the
ghostpad), calling gst_ghost_pad_internal_activate_push_default(), which
again will call gst_pad_activate_mode() on the original ghostpad.

By simply returning TRUE in
gst_ghost_pad_internal_activate_push_default() the redundant call to
gst_pad_activate_mode() (for the same pad) is avoided.
Comment 1 Sebastian Dröge (slomo) 2016-02-16 16:46:34 UTC
But now if the proxypad is activated, the ghostpad would not be activated anymore. Or am I missing something here?
Comment 2 Håvard Graff (hgr) 2016-02-17 10:08:10 UTC
Created attachment 321469 [details] [review]
ghostpad tests

I easily admit to not having the full picture here in mind, but these simple tests pass with these pads, and here there are no explicit activation of the ghostpads in the test, meaning they are being activated regardless since in both cases the test passes with buffers being passed on the pads.

Also, this does not break any of our tests (and we are very found of high-level bins, so lots of ghostpads everywhere) as well as it does not seem to break any upstream tests either.
Comment 3 Sebastian Dröge (slomo) 2016-02-17 10:32:20 UTC
Actually makes sense. The ghostpad is activated "automatically" from the outside (element state change or gst_pad_set_active() by the creator of the ghostpad), the proxypad can't be activated from the outside and only from the ghostpad. So what I described can never happen.

Thanks for the tests though :)
Comment 4 Sebastian Dröge (slomo) 2016-02-17 10:32:44 UTC
commit 87c2254b1d1e5d3478150545e97915fc8dab4a5a
Author: Havard Graff <havard.graff@gmail.com>
Date:   Wed Feb 17 11:02:34 2016 +0100

    ghostpad: add some tests for activation
    
    https://bugzilla.gnome.org/show_bug.cgi?id=761913

commit ab55ad7eaad4fa2c0b16c789350e882cf70a27ed
Author: Stian Selnes <stian@pexip.com>
Date:   Wed Jan 27 13:20:23 2016 +0100

    ghostpad: Do nothing in _internal_activate_push_default
    
    When calling gst_pad_activate_mode() on a ghostpad
    gst_ghost_pad_activate_push_default() will be called. This will call
    gst_pad_activate_mode() on the proxypad (which is internal of the
    ghostpad), calling gst_ghost_pad_internal_activate_push_default(), which
    again will call gst_pad_activate_mode() on the original ghostpad.
    
    By simply returning TRUE in
    gst_ghost_pad_internal_activate_push_default() the redundant call to
    gst_pad_activate_mode() (for the same pad) is avoided.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=761913