I’ve noticed that gst-device-monitor does not detect when a Source/Monitor device is removed or added. When I retrieve the list of currently available devices, the monitors are correctly listed. However, if a change occurs (e.g., a monitor is connected or disconnected), the GStreamer device monitor does not receive any event or message on the bus.
This appears to be a bug in the device monitoring functionality. It affects dynamic detection of display sources, which is critical in applications where monitors may be connected or disconnected at runtime.
Is this a known limitation or a bug in GstDeviceMonitor? If not, I’d like to report it properly.
I am using gst-device-monitor-1.0 -f on Windows with GStreamer 1.26.0. It works well for detecting dynamic device changes such as webcams and microphones — they are correctly detected when connected or disconnected.
However, display monitors (device class: Source/Monitor) are not detected dynamically. When I connect or disconnect a monitor, no event is emitted on the GStreamer bus. The only way to update the device list is to restart the monitor tool.
When I list the available devices manually, display monitors are correctly shown. My GStreamer setup uses the d3d11screencapturesrc and d3d12screencapturesrc APIs. Here is an example of a display device as reported:
Looking at the D3D device provider, there is indeed no support for dynamic devices, it’s only a static listing. I guess it would need to be implemented.
Note that as the maintainer of GstD3D11/12, I’m focusing development solely on D3D12, while D3D11 is mainly maintained for legacy compatibility. Contributions to GstD3D11 are still welcome, of course
I’m currently testing GStreamer with multiple monitors connected to my system, and I’ve encountered an unexpected behavior when using gst-device-monitor -f to list available video sources (specifically display/screen capture sources).
Here’s the scenario:
I have two monitors connected and gst-device-monitor lists both displays correctly.
When I disconnect the secondary monitor (the non-primary one), I receive a device removed event for both displays, followed immediately by a device added event for the remaining (still connected) monitor.
If I have a running pipeline that captures from the still-connected display, disconnecting the secondary display causes the pipeline to crash, because the source device disappears momentarily and is re-added under (apparently) a different ID.
This seems odd because:
Disconnecting one monitor shouldn’t affect the availability or identity of the other.
The ID of the remaining display should ideally stay the same, especially if it’s still physically connected and active.
When the primary display is removed, I would expect a “device removed” event for it, and perhaps a “device property changed” event for the other monitor (e.g., it became the new primary), rather than a full remove + re-add cycle.
Questions:
Is this behavior intentional, or is it a bug in how gst-device-monitor or the underlying screen capture source handles hotplug events?
Should the device ID of a monitor change just because another monitor was disconnected?
Questions: