VideoCapture resolution fallback behavior across V4L2 and GStreamer backends

Goal

Request a specific frame resolution through VideoCapture::set(CAP_PROP_FRAME_WIDTH, ...) and CAP_PROP_FRAME_HEIGHT on Linux, then verify that the captured frames match the requested dimensions.

Constraints and uncertainty

The OpenCV documentation does not guarantee that the requested width and height are honored. On V4L2 the driver may ignore the property if dynamic resolution changes are unsupported; on GStreamer the pipeline may negotiate a different resolution; on DirectShow the property is not implemented at all. When a resolution is unsupported, OpenCV silently falls back to the nearest supported resolution—often the device default—without raising an error or warning.

There is no cross-platform API in OpenCV to enumerate the resolutions a camera actually supports, so applications cannot programmatically discover valid values before calling set().

Questions

1. Is there a reliable, backend-agnostic pattern to detect that the active resolution differs from the requested one immediately after opening the capture?
2. Can an application query the list of supported resolutions without invoking platform-specific ioctl or GStreamer calls outside of OpenCV?
3. Does any backend expose a callback or property change notification when the negotiated resolution changes after set()?