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 590942 - avoid recalculating caps in basetransform
avoid recalculating caps in basetransform
Status: RESOLVED DUPLICATE of bug 662291
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: Stefan Sauer (gstreamer, gtkdoc dev)
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-06 12:53 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2011-11-08 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
cache previous results and reuse (5.48 KB, patch)
2009-08-06 12:54 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2009-08-06 12:53:56 UTC
gst_base_transform_getcaps is called quite often and even with same parameters. It would be nice if we can avoid rerunning all the calculations in those cases.

Templatecaps don't change. If we can assume that _transform_caps() only depends
on its inputs, we can cache results and avoid recalculation intersects.

The attached patch does that. I don't see regressions from unit-tests, nor from totem, rythmbox, buzztard, pitivi and jokosher. Is it safe to do this?
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2009-08-06 12:54:27 UTC
Created attachment 140018 [details] [review]
cache previous results and reuse
Comment 2 Wim Taymans 2009-08-21 10:32:25 UTC
It's not safe as the caps depend on what gst_base_transform_transform_caps() returns, which can change when, for example, the properties of an element change (capsfilter or videobox or something else).

Maybe if the element can notify basetransform that the transform caps would change results, it could clear the cached caps and then it would work. We need to figure out what elements are affected first.
Comment 3 Sebastian Dröge (slomo) 2011-05-30 16:02:50 UTC
It also depends on the peer caps over which we have absolutely no control here.
Comment 4 Vincent Penquerc'h 2011-11-08 12:36:43 UTC
Something like this was actually committed recently (168e5c0abb4c33de12c685e0efda6d4f9efdab2f, plus a few later fixes).
So marking as resolved duplicate, even though that other bug is newer.

*** This bug has been marked as a duplicate of bug 662291 ***