D3d11videosink or glimagesink, which element is better to use?

Application Development
1

Hi,

We have a C++ application to recover stream video from a camera, apply some processing on the video frames and display the processed stream video on our gui (qt application).

To do that, we have 2 pipelines :
Recover pipeline : udpsrc–>rtpvrawdepay–>appsink
Display pipeline : appsrc–>queue–>videoconvert–>videocrop–>d3d11videosink

And we have a callback on “new-sample” from the recovering pipeline to process frames. We also use gst_video_overlay_set_window_handle to display video in our qt widget.

All is OK except some glitches, like if frames are interlaced. If in the callback, we replace the frames of the camera by colored frames (one frame white, next frame black, next frame blue, next frame red, etc …), we note that frames displayed are effectively interlaced : instead to have a frame white then a frame black, etc we have a frame with several colors.

If we replace element d3d11videosink by glimagesink we no longer have a problem (no glitches, no frames interlaced). But we thought that d3d11 was better to use on Windows platform instead of glimagesink.
So is it a problem to use glimagesink on Windows platform ?
Is there a problem with d3d11videosink ? Are we missing some parameters ?

(Environment : Windows 11 - gstreamer 1.22.6 - Qt C++)

Thanks for your help.

2

can you share simple test code or gst-launch line to reproduce the issue?

3

Hi,
I tried to write a simple test code to reproduce the issue with an mp4 video in entry instead of our camera stream … but impossible to reproduce it !
I can share our code with the problem but I don’t know if it will be useful for you, tell me.
Note that if we add the element d3d11deinterlace to our display pipeline, no more problem :
appsrc–>queue–>videoconvert–>videocrop–>d3d11deinterlace–>d3d11videosink

We can work like this, no other fix is expected but we would like to understand why this element is useful.

Thanks.

4

d3d11deinterlace will upload frame to d3d11 texture then convert to NV12 format, it may make differences but d3d11deinterlace should be unnecessary unless the stream is actually interlaced

5

Ok, thanks for answer. We continued to investigate and the problem was not on d3d11videosink but on the way to push buffers on our callback. And so we effectly no need of d3d11deinterlace.