[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 #12 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2012-09-21 01:52:17 UTC ---
(In reply to comment #11)
> It is actually already noted in Comment #3 that those fields 'are created by
> standard videoinfo'.  As such, there is not really something wrong with having
> those on the src pad caps (and afaik there could even be more than those
> removed in the patch).

It's a convention. Caps set downstream shall be a subset of the caps we query.
Videomixer currently add those two fields (via the GstVideInfo utilities).
Adding extra fields does not respect the convention.

> 
> It seems/feels somehow more appropriate for getcaps to remove all but the
> relevant fields (from the src pad caps it starts with), where relevant fields
> are defined as those that it requires to be equal for all streams (in setcaps)
> (and where "all but" means preferably not 'hardcoding' the fields to be removed
> but rather those to keep).

I'm not this is a good approach for sink_getcaps(). In the end, the videomixer
would endup hiding caps that might be important, or might enable other use
cases. I think it's fine for the videomixer to only change the capabilities it
knows about and can handle.

On the ohter side, the src_setcaps() could be implemented better by iterating
the fields in caps from gst_video_info_to_caps() and fixate the peercaps for
fields that actually exist. This would prevent any field to be introduce by
videomixer. Not sure how urgent this is though, the attached patches are very
good start into the right direction.

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