[Bug 684237] videomixer: Caps negotiation does not always work

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=684237
  GStreamer | gst-plugins-good | git

--- Comment #6 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2012-09-18 14:21:31 UTC ---
(In reply to comment #5)
> Those are indeed not all atomic and allows races, but I do not see the problem
> so much in the current design, but within videomixer2 itself.

We'll I've been on that with Olivier Crête for few days (there is similar
issues in liveadder and adder element, probably all N-1 elements). And it's a
really hard problem. At the moment, we focus on getting the initial negotiation
to work, renegotiation seems olmost impossible.

> 
> That is, it returns getcaps with possibly "extra fields", for which it/we know
> that those might lead to this caps subset problem further upstream.  On the
> other hand, its own checks in setcaps only check for equal format and par.

Good, point, the custom accept caps is probably to help with that.

> 
> So, if the latter (freedom) is indeed what it can handle, it should report as
> such in getcaps (by definition) (and not have additional fields/restrictions in
> there).  If it can not handle it, then setcaps is at fault to accept it.

I agree, the get caps might not be perfect. But that freedom is also limited,
since all the sinkpad must send the same pixel format. What happens is that you
have no guaranty that all elements choose the same format (order of caps result
in luck most of the time). I do think there exist a solution, but it's going to
be complex, and races will be hard to solve. If the negotiation was a single
atomic operation, the solution would have been slightly simplier.

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