[Bug 755237] Caps Feature Negotiations have bad defaults

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755237

--- Comment #5 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Can you bring a real arguments, accusation are no rationale. If you stick with
rationales, we'll manage to get somewhere. Being polite and trying to
understand why there is a debate about whether or not an existing (and
deployed) implementation is correct is for me the way to go. Also, nothing of
this will change before 1.8, so we have plenty of time to think about it.

Caps features have worked this way since the day they where introduced. I have
personally nothing to do with that, I'm only acting as Devil's Advocate here.
memory:None (consistency requires camel case here) could be an option. 

Personally, I think not specifying memory:SystemMemory but specifying other
features is creating confusion, and shall never be used.

One known reason why adding a default memory:SytemMemory if there is not
memory: already in place is inconvenient is that it requires parsing all the
features already in place. This is a very costy operation during caps
negotiation. Caps feature name are free-form. Do you have a solution to that,
that would not require parsing every strings ?

(a side note, Arnaud Vrac and I have manage to successfully implement
OverlayComposition in many elements, even though some of it didn't make it for
1.6. We do believe the API works, hence it's not fundamental to change it, if
it can be changed, as ABI and API compatibility is very important, even when we
do mistake)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.