GNOME Bugzilla – Bug 764930
videomixer can not set opaque texture when its formats is AYUV.
Last modified: 2018-05-06 13:10:54 UTC
When you have 2 inputs in AYUV format go to videomixer, when you make a texture opaque, this one is never completely opaque. Exemple in pipeline follow: gst-launch-1.0 videotestsrc pattern=4 ! "video/x-raw, width=(int)426, height=(int)478, format=(string)AYUV" ! videomixer background=2 sink_0::xpos=800 sink_0::ypos=200 sink_1::zorder=2 sink_0::zorder=1 sink_1::alpha=1.0 name=videomixer ! videoconvert ! xvimagesink videotestsrc pattern=2 ! videoscale ! videoconvert ! "video/x-raw, width=(int)1280, height=(int)720, format=(string)AYUV" ! videomixer. In this exemple, when have a black texture or videomixer set opaque (sink_1::alpha=1.0) but in the result whe can see a block red in background.
Not sure what I'm supposed to see? The above pipeline seems to show solid black for me. With sink_1::alpha=0.98 I can just about make out the rectangle. Also, you should probably move to compositor to see if it still happens there, I don't think anyone is going to fix anything non-trivial in videomixer.
Hexdump of pixels shows mostly ff 12 80 80 with some ff 11 80 81.
Created attachment 325779 [details] image source
Created attachment 325780 [details] image result
I made another test where I replaced a black texture from videotestsrc by an image created on gimp. pipeline exemple: gst-launch-1.0 videotestsrc pattern=4 ! "video/x-raw, width=(int)426, height=(int)478, format=(string)AYUV" ! videomixer background=2 sink_0::xpos=800 sink_0::ypos=200 sink_1::zorder=2 sink_0::zorder=1 sink_1::alpha=1.0 name=videomixer ! videoconvert ! xvimagesink filesrc location="test_color.jpeg" ! jpegdec ! imagefreeze ! videoscale ! videoconvert ! "video/x-raw, width=(int)1280, height=(int)720, format=(string)AYUV" ! videomixer. You can found in attachment the image created on gimp and the result image.
Sorry no one ever looked at this in more detail. videomixer has been superseded by compositor/glvideomixer now. Please re-open this bug or open a new one if the issue still applies with recent gstreamer (>= 1.14) and these elements.