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 796569 - d3dvideosink: videocrop results in black screen
d3dvideosink: videocrop results in black screen
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.14.1
Other Windows
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-12 14:33 UTC by Colin
Modified: 2018-11-03 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Colin 2018-06-12 14:33:47 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
Comment 1 Nicolas Dufresne (ndufresne) 2018-06-12 14:56:27 UTC
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).
Comment 2 Colin 2018-06-12 15:53:37 UTC
We are looking for a proper fix but I don't feel skilled enough on this module to fix it...
Comment 3 Nicolas Dufresne (ndufresne) 2018-06-12 18:04:13 UTC
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.
Comment 4 GStreamer system administrator 2018-11-03 14:26:25 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/734.