[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 #15 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-09-21 14:33:07 UTC ---
I see nothing in that document that suggests such a "convention" [*].  All it
says is that downstream is queried for caps [**] and then the element (i.e.
videomixer) still decides what caps to produce, and so it can perfectly decide
to produce 'full src caps' (as come up with by videoinfo).  If needed, to stop
all this misunderstanding/misinterpretation, please indicate and specify a lot
more clearly what "convention" coming from where (precisely).

Furthermore, a search will show that gst_video_info_to_caps *is* used
elsewhere, most notably in the videodecoder base class, and so all videodecoder
will produce caps that way.  So I see no sense in trying to hack up our own
standard API by starting to "patch away" those fields in videomixer src caps
but not in a whole lot of other elements, do you? 

And no, those fields do not have to be in GST_VIDEO_CAPS_MAKE, because that is
a macro meant for template caps, and those do not need to specify all fields
the final actual caps will have (though the actual final caps should have all
fields that are specified in template caps).

And what I am also trying to explain, is that it does not matter how videomixer
is written *now* (why do we patch stuff?) and there is no law to keep
videomixer written as it is, i.e. having all caps fields it comes up with
downstream also appear upstream.

And finally, in that regard, videomixer2 is also kind of (pretty) wrong in that
when queried for caps it does not consult downstream for caps either (simply
takes either current src caps or its own pad template, so not really doing
[**]).  This is not optimal since it is *convention* to also consider
downstream requirements (e.g. some encoder or whatever).

So, IMO:
* nothing wrong with src caps as produced by video_info_to_caps (as in other
elements).  If you really do not like the extra fields (for some reason
preferably different than "how it is written now"), then maybe you could query
downstream for caps and somehow chuck out fields that are not in those?
* videomixer sink_getcaps could/should also consider downstream caps
requirements (yes, in addition then to the upstream ones due to videomixer
peculiarities to try and keep all streams compatible)

[*] the only place where the word convention appears is:
- src pad always decides, by convention. sinkpad can suggest a format
     by putting it high in the caps query result GstCaps.
--> (videomixer) src pad decides, so it can have all the video_info_to_caps
fields in there it wants

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