[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 #13 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-09-21 07:46:10 UTC ---
(In reply to comment #12)
> (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.

Never heard of this one before (in as far as 'we query' is fairly ambiguous);
specified where?  And by adding fields to the caps downstream, they actually
are a subset (set-wise) of the upstream caps.

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

hiding (part of) caps ? If they are/were important, then why does the setcaps
part not know/care about them.

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

But anyway ...

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