Software screen capture
Topics¶
Windows DirectX11 screen capture¶
The previous version of HyperHDR introduced screen capture on Windows systems, fully utilizing the hardware acceleration of the graphics card. Thanks to it, automatic color space conversion occurs there, but that's not all.
Another problem is sending the captured image from the graphics card memory to the computer memory: we do not want to fill this bridge, which could have a negative impact on the use of the PC: for example, cause jerking in games. Here, pixer & vertex shaders implemented in HyperHDR come to the rescue, which scale the bitmap already in the graphics card memory, which is the optimal solution.
HyperHDR v21 brings another solution that may interest gamers equipped with multiple monitors: multi-monitor support. Simply select the multi-monitor option for a given graphics adapter and HyperHDR will capture the image from all monitors, later combining them into one. Full hardware acceleration is always working here, which will handle even situations when the monitors have different resolutions or, for example, one of them is SDR and the other is HDR.
The DirectX grabber's performance is very good and allows you to save buying a USB grabber and HDMI splitter: everything is done in software. There is one case you need to remember though: it will not capture copy-protected streams such as commercial streaming services.
Configuration of Windows DirectX11 screen capture¶
Open the Video capturing tab and scroll down the page. Now if you want, you can select a video device from the list or enable multi-screen capture. Once you have finished configuring DirectX Grabber and saved it, set enable system capture and save the changes again.
Now you can open the video live preview window and verify if everything is OK.
The example below shows an active multi-monitor configuration where the displays have different parameters.
Just increase re-order mode till you get correct order for multi-display mode in the video live preview
Linux Pipewire Portal screen capture for Wayland¶
1. Run as Application (Not Daemon)¶
The PipeWire grabber will not work if HyperHDR is running as a system service (daemon). Due to Wayland security, the grabber must be launched as a user application within an active session to gain screen access.
2. Hardware Acceleration (DMA/EGL)¶
To use the high-performance DMA/EGL mode, vendor-specific drivers are required. Standard open-source drivers usually lack the necessary support for hardware buffer sharing.
- Intel: Requires
intel-media-va-driver-non-free(the standardintel-media-va-driveris often insufficient for DMA). - NVIDIA: Requires proprietary NVIDIA drivers (the
nouveaudriver most likely won't provide DMA mode in Pipewire).
Note: If these drivers are missing, the system will use File Descriptor (SHM) mode. It remains functional, but lacks the full performance of zero-copy acceleration.
3. Configuration Steps¶
In the "Software Screen Capture" tab, ensure that Pipewire is listed as the automatically selected grabber. (Note: Pipewire will not be available if HyperHDR is running as a Linux system service).
Under "Instance Screen Capture", check "Enable system capture". This should trigger a monitor selection window managed by Portal. If the window does not appear, you should analyze both the HyperHDR and system Portal logs to identify why the selection prompt is not being presented.
4. Verification and Stability¶
Once successful, you can verify if the video stream is working correctly in the live preview. Check the HyperHDR logs for more detailed technical information, such as whether DMA mode was activated or if it fell back to file descriptors. Please note: HyperHDR only reports its capability to handle DMA mode; whether Pipewire actually provides it depends on your GFX driver, Pipewire version or the Wayland compositor rather than our application itself.
We strongly recommend enabling the "Disable on OS lock or monitor off" option in the "General" tab. This minimizes the risk of the grabber attempting to resume before the user session or display are fully re-initialized. Such timing issues can cause Pipewire to reject the saved session token, forcing you to manually re-select the monitor.