[gstreamer-bugs] [Bug 617045] [caps] New method for intersecting caps while retaining order

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=617045
  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
   is ignored.

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
too
complicated. This model favours 'small' conversions to get an overall best
format.

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.