[d3d11screencapturesrc] standard resolutions works well, 3440x1440 not.

Nicolas Dufresne nicolas at ndufresne.ca
Wed Dec 13 15:15:13 UTC 2023


Hi,

Le mercredi 13 décembre 2023 à 11:05 +0100, Davide Perini via gstreamer-devel a
écrit :
> Hi all.
> I'm using this pipeline to capture the screen using GStreamer Java:

The mailing is is getting quite now that we have discourse.gstreamer.org,
perhaps you'd like to consider for future help request.

> 
> ./gst-launch-1.0 d3d11screencapturesrc ! d3d11convert ! 
> "video/x-raw(memory:D3D11Memory),width=3840,height=2160,sync=false" ! 
> autovideosink
> 
> this pipeline works well with "standard resolutions" like 3840x2160 but 
> it doesn't work well with more stretched resolutions like 3440x1440.
> 
> There are resolutions like 480x270 that works well with NVIDIA GPUs but 
> not with AMD ones.
> 
> What do I mean for "it doesn't work well"?
> 
> The resolutions "that doesn't work well" seems to capture the screen 
> with some pixel shifting,
> I attach an image captured using a resolutions "that works well" and an 
> image that captures the same image on a resolution "that doesn't works 
> well".
> As you can see in the OK image there is a black background with a white 
> square on it, in the KO image the white square is completely "cutted" 
> like if there are pixel shifting.
> 
> If I use that pipeline using the gst-launch-1.0 command, I can't 
> reproduce the problem,
> if I use the GStreamer Java binding, the problem is there.
> 
> You could say me that there must be a problem in the Java bindings, but 
> what kind of problem could be there?
> What's the difference between this resolutions, for example 3840x2160 
> and 3440x1440?
> And why some resolutions affects AMD GPUs and not NVIDIA ones?

The best is to fix the underneath element code when possible. The image you
attach. If you think you have precise enough information to reproduce the issue,
I'd suggest to open an issue in gitlab, you can attach the relevant jpeg to show
the expectation.

The picture you are showing demonstrate that the stride is incorrect, which is
likely a GStreamer bug.

Nicolas

> 
> Is there a way to "detect/recognize" this problem in order to switch to 
> another pipeline that works well with all resolutions and GPUs like this 
> one?
> ./gst-launch-1.0 d3d11screencapturesrc ! d3d11convert ! d3d11download ! 
> "video/x-raw(memory:SystemMemory),width=3440,height=1440,sync=false" ! 
> autovideosink
> 
> Any ideas or toughts that points me a step further in understanding this 
> problems will be really apprecaited :)
> 
> Thanks
> 
> 



More information about the gstreamer-devel mailing list