videoaggregator: Forbids mixing interlaced and progressive inputs
Relevant code is in gst_video_aggregator_pad_sink_getcaps()
:
has_interlace_mode =
gst_video_aggregator_get_sinkpads_interlace_mode (vagg, NULL,
&interlace_mode);
n = gst_caps_get_size (srccaps);
for (i = 0; i < n; i++) {
s = gst_caps_get_structure (srccaps, i);
[...]
if (has_interlace_mode)
gst_structure_set (s, "interlace-mode", G_TYPE_STRING,
gst_video_interlace_mode_to_string (interlace_mode), NULL);
}
This way we will fail negotiation if there's a mismatch.
While this is in theory correct, I guess, in many cases one wouldn't care if the interlaced content is mixed as if it was progressive.
And even more so, if we want to be theoretically correct then the mixing of interlaced content is broken right now anyway. If you have two interlaced inputs and mix them with an offset of 1 (or any odd number) lines, you would mix different fields. Similarly if the two interlaced inputs disagree in tff/bff.
The code in question was added in https://bugzilla.gnome.org/show_bug.cgi?id=754495 but I think this is wrong. We should remove that for now and always output progressive until we implement proper interlaced mixing (see above), if ever.
Opinions? Should this be considered a blocker for 1.16, @tpm?
Also CC @thiblahute @thiagoss @meh