GNOME Bugzilla – Bug 777820
vaapipostproc: intel driver add green border on odd vertical scaling with YUY2
Last modified: 2018-11-03 15:48:37 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
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?
Can you confirm this is an issue only with xvimagesink?
I have this problem here with appsink. But it is not easy to show it with appsink.
So it is not only with xvimagesink.
With appsink I also see a green border on the right side of the image, not only on the bottom line.
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.
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.
-- 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/gstreamer-vaapi/issues/47.