[Bug 784010] New: Compositor produces broken video (with green stripes) when compositing BGRA and I420 that has been scaled

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784010

Bug ID: 784010
Summary: Compositor produces broken video (with green stripes)
when compositing BGRA and I420 that has been scaled
Classification: Platform
Product: GStreamer
Version: unspecified
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-bad
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@siobud.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

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 Loading Image...

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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784010

--- Comment #1 from Sean-Der <***@siobud.com> ---
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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784010

--- Comment #2 from Sean-Der <***@siobud.com> ---
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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784010

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #3 from GStreamer system administrator <***@gstreamer.net> ---
-- 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.