caps: Using gst_caps_fixate() on src pad leads to lies in the caps
@ndufresne
Submitted by Nicolas Dufresne Link to original bug (#797142)
Description
The default implementation of fixate in basesrc is based on gst_caps_fixate(). This though can lead to terribly lies in the resulting caps if downstream element uses ranges or set to explicitly state what is supported.
As in:
udpsrc caps="video/x-h264" ! h264parse ! avdec_h264 ! fakesink
avdec_h264 sets the alignment to { au, nal }, in order to ensure that it's one of these two alignment that are provided. udpsrc, which uses BaseSrc default, will happily pretend to produce:
video/x-h264, alignment=(string)au, stream-format=(string)avc
This is highly problematic, since we now lie to h264parse, triggering optimization that should not.
The downstream solution to that is to remove the alignment and to write code in When we receive that caps that check that alignment is present. That's not a great solution because it requires coding the requirements and also it reduce the quality of the documentation.
While I'm under the impression this may break some valid use cases, I'd like to start experimenting a solution that would make our caps negotiation more strict. My first proposal would be to create a new version of gst_caps_fixate(), let's say gst_caps_fixate_known (caps, known_field), or gst_caps_fixate_from_template (caps, template). The idea is that the opration would first remove all the unkmown field before fixating. As a side effect, in the previous example, udpsrc would negotiate just "