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 382223 - [decodebin] more delayed linking
[decodebin] more delayed linking
Status: VERIFIED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal blocker
: 0.10.11
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-12-04 11:44 UTC by Wim Taymans
Modified: 2006-12-07 11:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch t handle more delayed caps cases (1.45 KB, patch)
2006-12-04 11:48 UTC, Wim Taymans 		accepted-commit_now Details | Review
don't register dynamic elements multiple times (3.54 KB, patch)
2006-12-04 16:55 UTC, Wim Taymans 		none Details | Review
Better patch (6.22 KB, patch)
2006-12-04 19:45 UTC, Jan Schmidt 		committed Details | Review

Description Wim Taymans 2006-12-04 11:44:53 UTC 
Seems like the code is there to handle delayed linking in the case of unfixed caps.
Comment 1 Wim Taymans 2006-12-04 11:48:01 UTC 
Created attachment 77627 [details] [review]
patch t handle more delayed caps cases

This patch calls the code path that handles delayed pad linking in the case of ANY caps on a new pad.
Also fixes some comments and debugging info.
Comment 2 Jan Schmidt 2006-12-04 12:49:36 UTC 
I was going to say do you think "(gst_caps_get_size (caps) != 1)" should become !gst_caps_is_fixed ()", since it's possible we might just have a range, but then I realised that in that case it must be a raw-range anyway to have any chance of ever succeeding anyway, and then the pad will be published already in the other if branch... so commit away.
Comment 3 Wim Taymans 2006-12-04 13:55:23 UTC 
        * gst/playback/gstdecodebin.c: (close_pad_link):
        Fix #382223, add more dynamic caps handling.
Comment 4 Wim Taymans 2006-12-04 16:55:24 UTC 
Created attachment 77657 [details] [review]
don't register dynamic elements multiple times

When a (broken) element both has dynamic pads and delayed caps, make sure we don't register the element as dynamic multiple times.
Comment 5 Jan Schmidt 2006-12-04 19:45:51 UTC 
Created attachment 77673 [details] [review]
Better patch

When an element has both dynamic pads and delayed caps, add an entry for each, but differentiate them by only setting the element var in the GstDynamic entry on dynamic element entries, and the pad var on delayed-caps pads.

Use a new method to determine whether an element has just become dynamic again in the unlinked handler.