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 658918 - [pad] set caps on pad before checking for peer
[pad] set caps on pad before checking for peer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.31
Other Linux
: Normal normal
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-13 13:39 UTC by Stas Sergeev
Modified: 2011-09-19 12:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the fix (1.94 KB, patch)
2011-09-13 13:39 UTC, Stas Sergeev
committed Details | Review

Description Stas Sergeev 2011-09-13 13:39:49 UTC
Created attachment 196371 [details] [review]
the fix

Hi.

Right now the setcaps handler won't activate on an unlinked pad.
This is a big inconvenience: I want the setcaps handler to link the pad
with the peer.
The attached patch makes this possible.
Comment 1 David Schleef 2011-09-17 19:40:43 UTC
(In reply to comment #0)
> I want the setcaps handler to link the pad
> with the peer.

Elements are not responsible for linking pads, applications are.  Perhaps you want to link elements in a caps::notify signal?
Comment 2 Stas Sergeev 2011-09-17 20:22:09 UTC
> Elements are not responsible for linking pads, applications are.
But bins are, too.
What my bin does, is to set the setcaps handler
for one of its elements's _src_ pad.
I wonder if it is a bad idea to set the setcaps
handler for the sub-element: it is certainly unacceptable
for sink pads, but for src - why not? I don't think some element
will want to set the setcaps handler for its src pad, so why
not doing that in a parent bin? Or is there any use for
the element itself to set the setcaps handler for its src pad?

> Perhaps you want to link elements in a caps::notify signal?
I'll take a look, thanks for the pointer.
Still I wonder if it is a bad idea to do it the way
I've done now.
Comment 3 Sebastian Dröge (slomo) 2011-09-19 07:59:48 UTC
It is, only the parent/owner of the pad should ever set the pad functions. Nonetheless I think this patch is correct, the pad caps should be set even if there's no peer at that point, the pad might be connected in the notify::caps handler. OTOH linking pads in notify::caps works definitely, decodebin2 does that.
Comment 4 Stas Sergeev 2011-09-19 10:57:50 UTC
OK, I converted my plugin to notify::caps (after all,
that was just a few lines of a change).
Believe it or not, but it still requires this patch,
both with gstreamer-0.10.31 and the latest git sources.
So I don't know when notify::caps used to work for you,
apparently not any recently.
Comment 5 Sebastian Dröge (slomo) 2011-09-19 12:15:36 UTC
You're right, decodebin2 always has the srcpads connected to a pad while waiting for notify::caps and then links the srcpad to the new downstream elements.


commit b090a376d4c6f5e797e2c24134020c9e727a72ab
Author: Stas Sergeev <stsp@users.sourceforge.net>
Date:   Tue Sep 13 17:04:31 2011 +0400

    pad: Set caps on pad before checking if the pad is linked
    
    This allows the setcaps handler and notify::caps to link
    the pad downstream and doesn't require hacks to always
    provide a peer to the pad, like in decodebin2.