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 777820 - vaapipostproc: intel driver add green border on odd vertical scaling with YUY2
vaapipostproc: intel driver add green border on odd vertical scaling with YUY2
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2017-01-27 10:01 UTC by Thomas Scheuermann
Modified: 2018-11-03 15:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Thomas Scheuermann 2017-01-27 10:01:54 UTC
vaapipostproc creates a green colored last line if the scaling value for the height is odd. It can be shown with the following pipeline:

gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080 ! vaapipostproc ! vaapih264enc ! h264parse ! decodebin ! vaapipostproc ! video/x-raw,width=861,height=411,format=I420 ! xvimagesink

Comment 1 Víctor Manuel Jáquez Leal 2017-02-03 11:58:12 UTC

Thanks for the report, and sorry for the late reply.

Strange, I only see this behavior when using xvimagesink, but no with vaapisink, glimagesink, clutterautovideosink nor ximagesink.

I wonder what is happening there? is it a problem in xvimagesink?
Comment 2 Víctor Manuel Jáquez Leal 2017-02-03 11:58:41 UTC
Can you confirm this is an issue only with xvimagesink?
Comment 3 Thomas Scheuermann 2017-02-08 08:43:02 UTC
I have this problem here with appsink. But it is not easy to show it with appsink.
So it is not only with xvimagesink.
Comment 4 Thomas Scheuermann 2017-02-08 08:44:51 UTC
With appsink I also see a green border on the right side of the image, not only on the bottom line.
Comment 5 Hyunjun Ko 2017-02-15 08:19:57 UTC
This is reproducible by the following pipeline.

gst-launch-1.0 videotestsrc ! video/x-raw,width=841,height=411 ! vaapipostproc ! xvimagesink
=> Green border. This is negotiated as YUY2

gst-launch-1.0 videotestsrc ! video/x-raw,width=841,height=411 ! vaapipostproc ! ximagesink
=> Fine. This is negotiated as BGRx

Probably, this is due to mismatch between size of real GPU mapped memory and calculated size by provided width/height
 when doing gst_video_frame_map/copy.
IIUC, in driver, VA surface's width and height is aligend to 64 (depending on HW chipset) for YUV formats, which means that
it's different from user-provided width/height.

I'm not sure how to handle this case properly.
Maybe if your appsink can get video meta from upstream (should be implemented by yourself),  you could manipulate raw day by given plane/stride/offset.

I don't know.
Comment 6 Nicolas Dufresne (ndufresne) 2017-02-15 17:09:35 UTC
Hardware scaler should scale to biggest but closest size and crop in order to compensate the limitations. I would suspect a bug, where the closest size is being picked instead of bigger closest.
Comment 7 GStreamer system administrator 2018-11-03 15:48:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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: