GNOME Bugzilla – Bug 796769
ksvideosrc: fails to initialize Datapath VisionRGB-E2S
Last modified: 2018-11-03 14:27:33 UTC
Created attachment 372982 [details] debugLevel6 I have a Datapath VisionRGB-E2S capture device. It is installed on windows and works fine using directshow. I am trying to open its stream through GStreamer, and the provided command by gst-device-monitor-1.0.exe fails with "reason-not-negotiated <-4>". I've added the gst-device-monitor output, and a level 6 debug output.
Did you try adding videoconvert, or jpegdec after it ?
I tested now, and nothing proposed seems to work. Even with a fakesink it doesn't work.
I was looking into the log and this part looked interesting. " failed to create/open KsClock filter supports 5 property sets [0] {7E9A3511-8465-4776-BFB8-070EE732B4C9} [1] {620F2F08-85E6-4212-89E4-4DB31036E090} [2] KSPROPSETID_VIDCAP_CROSSBAR ... ... ksvideosrc ksvideohelpers.c:199:ks_video_format_to_structure: Unknown DirectShow Video GUID e436eb7a-524f-11ce-9f53-0020af0ba770 WARNING **: ks_video_format_to_structure returned NULL " It seems, that the format is not supported which is RGB8 according to this page https://docs.microsoft.com/en-us/windows/desktop/wmformat/media-type-identifiers
Update: I think the device can work if all caps are set to the right values (which are not automatically detected by gstreamer). I started getting fakesink to work now.
Ah, so that's likely a depth sensor. R is most likely mapped to the luma, and G to the distance. I'm not sure this format match very well video/x-raw, though we could take it literally and render R and G as defined. So we have two options, new media type, or introducing RG88 and colorconvertion for it in libgstvideo.
To be honnest, this is weird, since nothing in the product description seems to lead to a depth sensor, RG88 seems like a complete non-sense for DVI capture: https://www.datapath.co.uk/datapath-products/video-capture-cards/vision-range/visionrgb-e2s Have you contacted datapath ?
Also, it's supposed to expose bunch of other formats according to the spec: RGB: 5-5-5, 5-6-5 or 8-8-8 (24bit/32bit) pixels YUV: 4:2:2, UYVY, YUY2, YVYU Do you mean the ksvideosrc fails on first unknown formats ?
To answer the questions, I think RGB8 (it's a B not 8) is set in the debug because maybe that's the default with ksvideosrc ? It's a simple capture device, and I've opened it through YUY2 format that needs to be defined. But there is a catch here : ksvideosrc can't open the device unless it is opened first at least once on GraphEdit/DShow. Then, ksvideosrc can open it. If the system reboots, it doesn't work anymore, and I need to reopen it in GraphEdit.
Sorry, I guess I need to wake up a little. So, according to https://docs.microsoft.com/en-us/windows/desktop/directshow/uncompressed-rgb-video-subtypes RGB8 is a 8 bit palette format, no wonder no one cared integrating that. I think it's fine to ignore that part. Ok this time looking at the logs you provided, the selected format is odd: video/x-raw, format=(string)YUY2, width=(int)2048, height=(int)4096, framerate=(fraction)10000/1, pixel-aspect-ratio=(fraction)12/11 It's probably a bug in the constraint calculated by ksvideosrc. The problem being pixel-aspect-ratio (not-negotatiated) but the framerate would make everything unusable, also I doubt the capture will work if the resolution does not match the remotely connected device (but the device may be scaling, I don't know). So I'd check this up with the following caps filter: ksvideosrc ! video/x-raw,width=1920,height=1080,pixel-aspect-ratio=1/1,framerate=60/1 ! ...
Actually I got my device working by defining at least the type, width, height and format ksvideosrc device-index=1 ! video/x-raw, format=YUY2, width=1920, height=1080 ! ... These parameters are copied from the directshow filter that needs to run first, otherwise gstreamer fails to open the device. Any change to the format which is different to what defined don't work. if you change the paramters from directshow filter options (GraphEdit), you need to update the gstreamer width/height, otherwise the same command won't work again. So now, it's an initialization problem for the device. And I don't know what to do for that. Is there any ideas or hints on how to fix this?
-- 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/747.