[Bug 691370] caps intersection is broken for channel-layout / bitmasks

[GStreamer (bugzilla.gnome.org)]

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

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #10 from Sebastian Dröge <slomo at circular-chaos.org> 2013-02-13 15:57:46 UTC ---
<__tim> slomo, I am not sure I agree about the channel mask thing
<slomo> __tim: how was this handled in 0.10?
<__tim> what is 'this' exactly now?
<__tim> the array was treated as a whole
<slomo> __tim: ah right, nevermind :)
<__tim> one problem is that we have added a new 'bitmask' type when we really
meant a 'channelmask' type, no?
<slomo> how do you mean that?
<__tim> something that might be correct for a bitmask in general might not be
correct for our channel masks
<slomo> __tim: i think the problem is more that there are different semantics
for unfixed channel masks (the current intersection works for that) and fixed
channel masks (where we have the problem)
<__tim> really?
<__tim> but we would never express unfixed possible masks as all bits set,
would we?
<slomo> __tim: and the relation between the channels and channel-mask fields in
the caps ($channel-mask needs $channels bits set for fixed caps, and >=
$channels bits for unfixed caps)
<__tim> but rather a list of possible combinations?
<__tim> (or just no field for 'everything goes')
<slomo> no, unfixed "everything possible" is all bits set
<__tim> right, and that's where the problems start, no? :)
<__tim> I note that there is not a single element that advertises a channel
mask with all bits set on its template caps
<__tim> and that special case is really the only justication for doing a
bitwise intersection, no?
<slomo> __tim: yes, not only "all bits set" but also the case when more bits
are set
<slomo> __tim: i think this is not used anywhere yet so could be changed (and
we just require a list of channel-masks instead)
<slomo> __tim: i probably was trying to be too clever there :)
<__tim> :)
<__tim> well, would you ever do something like channels=2,
channel-mask=FR,FL,RR,RL to indicate 'any two channels of those' ?
<__tim> I don't think that's something you'd do in practice
<slomo> __tim: so the change would be to replace the intersection, union,
subset, etc operations with the ones for integers
<slomo> __tim: or am i missing something?
<slomo> currently they all do set operations on the bits
<__tim> I think so
<slomo> ok

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