[gstreamer-bugs] [Bug 353970] [capsfilter] doesn't filter caps correctly

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=353970
  GStreamer | gstreamer (core) | git

Benjamin Otte (Company) <otte> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |otte at gnome.org

--- Comment #7 from Benjamin Otte (Company) <otte at gnome.org> 2010-03-27 23:07:28 UTC ---
Yay, another reason to do mandatory and optional flags for caps fields. :)

I should note I'm generally against having a special algorithm for capsfilter,
as it's very confusing if gst-launch uses a different intersection algorithm
from everything else using caps.

Long story with lots of theory: The problem with this is (and always has been)
the interpretation of optional fields. Optional fields were introduced as a
shortcut to defining caps, so you don't need to write down all fields if you
didn't care about them. This is mostly used in capsfilter, but is also used in
generic templates (which just return "audio/x-raw-int"), though elements have
been getting more and more strict in their definition of template caps. In this
initial sense omitting a field meant a shortcut to ANY.

Unfortunately this has consequences for fixation. A fixed caps is not really
fixed, because all undefined fields are still set to ANY: You can intersect the
fixed caps "audio/x-mp3" with "audio/x-mp3, parsed={false,true}" and the result
is non-fixed. This is an inconsistency in the caps system large enough to
attract more bugs than Starship Troopers, oftentimes in the form of weird
incompatibilities or broken output files (see the caps above for an example).
Luckily g_return_if_fail(gst_caps_is_fixed()) helps against the SEGVs usually.

I've been thinking about this problem for a long time, but never came up with a
satisfactory answer that would solve this without breaking too much of what
people expect.
But I do believe that custom ad-hoc solutions like Tim's patch don't help, they
just add confusion (though they intuitively feel right).

-- 
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.