[gstreamer-bugs] [Bug 617045] [caps] New method for intersecting caps while retaining order
bugzilla at gnome.org
Fri Jan 7 07:13:45 PST 2011
GStreamer | gstreamer (core) | git
--- Comment #20 from Wim Taymans <wim.taymans at gmail.com> 2011-01-07 15:13:39 UTC ---
After some more thinking about it:
1) The zigzag simulates a simple cost model where each caps list entry has an
equal weight. It then orders the resulting intersection based on the lowest
sum of weights. This model would find an 'overall' fair intersection as seen
in Comment #11.
2) The sorted one tries to maintain the order of the downstream caps as much as
possible. This by definition tries to maintain the same caps order as far
upstream as possible. It is not fair because the order of the upstream caps
1) Is easy to throw off balance. When something is not the first element of the
list, we don't really know how much worse it is compared to the top of the
list because it uses a fixed cost model (comment #11). Trying to add more fine
grained sorting weights (comment #16) might make things better but it sounds
complicated. This model favours 'small' conversions to get an overall best
2) Tries to minimize conversions as much as possible but can cause 'very
expensive' conversions because there is no fair cost model. This is the case in
comment #15. The source has no other option than taking the cost of providing
the first downstream format (and doing the conversion) because it can't know if
any other format is going to be even more expensive downstream.
The current 1) seems to fail because it uses a too broken cost model, so, 2)
seems like it might indeed work better. Let's try this after the release then.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs