I am pretty sure that https://bugzilla.gnome.org/show_bug.cgi?id=754465 should be reversed has it now addresses no issues and adds unnecessary complexity to the compositor.

See https://bugzilla.gnome.org/show_bug.cgi?id=757610 for related discussions.

This pipeline was used for testing:

compositor name=mixer ! videoconvert ! autovideosink \
videotestsrc ! queue ! mixer. \
udpsrc port=9000 ! textrender ! videorate drop-only=true ! video/x-raw, framerate=10/1 ! queue ! mixer.

Starting it and sending an udp packet to port 9000 will result in this error:

ERREUR¦: de l'element /GstPipeline:pipeline0/GstCompositor:mixer¦: At least one of the input pads contains alpha, but downstream can't support alpha.
Information de d¦bogage suppl¦mentaire¦:
../../../../gst-plugins-bad-1.6.3/gst-libs/gst/video/gstvideoaggregator.c(587): gst_videoaggregator_update_converters (): /GstPipeline:pipeline0/GstCompositor:mixer:
Either convert your inputs to not contain alpha or add a videoconvert after the aggregator

This error is expected and clear. Adding the converter as suggested works and the pipeline will run fine with it.

Now, reverting the fix for 757610 (by simply forcing has_alpha to TRUE in gst_videoaggregator_pad_sink_getcaps()) and re-running the above test will yield the exact same result. The fact that downstream does not support alpha is handled (in all cases) in gst_videoaggregator_update_converters(). This method properly detects that downstream does not support alpha and provides an explicit error message when needed.

This leads me to believe that the fix for 754465 is now obsolete and only adds unneeded complexity to the compositor code.