GNOME Bugzilla – Bug 796569
d3dvideosink: videocrop results in black screen
Last modified: 2018-11-03 14:26:25 UTC
gst-launch-1.0.exe videotestsrc ! videoscale ! video/x-raw,width=1280,height=720 ! videocrop top=2 left=0 right=0 bottom=0 ! videoconvert ! d3dvideosink This pipeline produce black screen on GStreamer 1.14.0 and 1.14.1 but works on v1.12.4 on two different computers. Removing the videocrop by setting top=0 or changing d3dvideosink to glimagesink works, the problem seems to be the interaction between videocrop and d3dvideosink on GStreamer 1.14.x
I bet d3dvideosink has a bad VideoCropMeta implementation. Do you have time to properly fix it or would you just want to revert back to software cropping in 1.12 ? (for which I can make a patchs, it a one liner).
We are looking for a proper fix but I don't feel skilled enough on this module to fix it...
Ok, prior to 1.14, it videocrop was doing the crop in software. If you go in d3dvideosink code, gst-plugins-bad/sys/d3dvideosink.c, and you comment out the line 467: //gst_query_add_allocation_meta (query, GST_VIDEO_CROP_META_API_TYPE, NULL); You'll revert back to the previous behaviour. Now, the problem is that with CropMeta attached to the buffer, one would expect that the caps width/height are larger then the crop rectangle. But the way it's implemented in GStreamer, the width/height is the display size. A larger display width/height would be mean to not just stretch but also scale up. This code seems to have never been tested, and is base on the assumption the the caps width/height is the size of the buffer before it was cropped. So as a side effect, in your case, you are asking D3D to crop rectangle (x, y, width, height) (0, 2, 1280, 718) a display buffer of size 1280x718. This is of course impossible. What need to be done (and that's why GstVideoMeta is strictly needed if crop meta is used) is to read the width/height from the attached src buffer GstVideoMeta. This one will say 1280x720, and then cropping this with rectangle (0, 2, 1280, 718) will be valid.
-- 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/734.