After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784010 - Compositor produces broken video (with green stripes) when compositing BGRA and I420 that has been scaled
Compositor produces broken video (with green stripes) when compositing BGRA a...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-20 18:45 UTC by Sean-Der
Modified: 2018-11-03 14:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sean-Der 2017-06-20 18:45:33 UTC
Using the following pipeline

gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, width=10, height=10, format=BGRA ! compositor name=c ! videoconvert ! ximagesink \
          videotestsrc ! video/x-raw, format=I420, width=1280, height=720 ! videoscale ! video/x-raw, width=1200, height=680 ! c.

I get video that looks like http://i.imgur.com/WK9bh9d.png

If you change the format to I420 on the first videotestsrc this issue goes away. I use the videoscale outside the compositor for better performance (works is spread across more threads it seems) if I don't I peg a single core much quicker.
Comment 1 Sean-Der 2017-06-21 05:48:21 UTC
I fixed this by setting the pixel-aspect-ratio (example pipeline below) while debugging I noticed that the videoconversion in the compositor was changing the height of the video

video/x-raw, format=(string)I420, width=(int)1200, height=(int)680, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)136/135, chroma-site=(string)mpeg2, colorimetry=(string)bt709, framerate=(fraction)30/1
to
 video/x-raw, format=(string)BGRA, width=(int)1208, height=(int)680, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)sRGB, framerate=(fraction)30/1

It was using the pixel-aspect-ratio, so by forcing it after the video scale it keeps the height/width (and the green lines go away)

gst-launch-1.0 videotestsrc ! video/x-raw, width=10, height=10, format=BGRA ! compositor name=c ! videoconvert ! ximagesink \
  videotestsrc ! video/x-raw, format=I420, width=1280, height=720 ! videoscale add-borders=false ! video/x-raw, width=1200, height=680, pixel-aspect-ratio=1/1 ! c. \

I would love to take this bug on (so I can understand the GstVideoAggregator and video convert code more) but would need someone to lead me in the right direction. Or maybe the behavior right now is fine, and I just don't fully understand
Comment 2 Sean-Der 2017-06-21 18:33:52 UTC
And one last time, here is the simplest pipeline I can make. Just realized the videoscale really has no part in this issue

gst-launch-1.0 videotestsrc ! video/x-raw, width=10, height=10, format=BGRA ! compositor name=c ! videoconvert ! ximagesink \
  videotestsrc ! video/x-raw, format=I420, width=1200, height=680, pixel-aspect-ratio=136/135 ! c.

I will probably take a crack at this during the weekend, but I realized a lot of bugs have cropped up from this. The quality of scaling has been really poor, and has gotten much better since over-riding the PAR. I will try to figure out the real purpose of PAR and if what I am seeing is actually even a bug
Comment 3 GStreamer system administrator 2018-11-03 14:10:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/574.