Drop frame rate/resolution of grabbers when source signal dies #93
Comments
|
OK, next version (v17) |
- upgrade Bootstrap from version 3 to 5 - replace and update most of UI components - software screen grabbers (Windows:DirectX11 / Linux:X11 / macOS:CoreGraphics) #46 - HDR available as a global component - automatic signal detection with learning capability - reimplemented backup import / export function for all instances' settings - current video stream information in the 'overview' tab - support for my new HyperSPI project (https://github.com/awawa-dev/HyperSPI) with awa_spi LED driver - new video stream crop method in JSON API - JSON API documentation in a form of live playground in 'Advanced' tab - LED grouping aka PC mode aka gradient mode - add timeout for the anti-flickering filter - translation resources are updated - new panel for easy video resolution & refresh mode selection - add release for AARCH64 architecture #68 - fix for WLED new network protocol #90 - fix missing Linux taskbar icon - support for libCEC 6.0.2 to turn on/off video & system grabber - support for libCEC to turn on/off HDR tone mapping with remote buttons - compatibility with QT6.2 (tested with the preview version/Vulkan/Windows) - lower CPU usage when automatic signal detection triggers 'nosignal' ('save resources' for software framerate decimation) #93 - standardize libJPEG-turbo library (where it's necessary) - fix values premature clipping in the LUT generator & SDR preview rendering fix, access available now from the menu ('Advanced' tab) - suppress most of external components' warning while building - faster image to LED colors transformation - import 'sparks' and 'system shutdown' effects to the new effect API #75 - better logging with instances' indexes - fix power saving issue with macOS port - fix memory leaks in SPI drivers
|
Since there is new automatic signal detection that based on the calibration data we can't change the video resolution. The only real option is the framerate. Most of grabber has only one framerate mode for selected resolution so we must lower frame-processing in software. Implemented in version 17 (beta for testing). Details in the change log. It causes quite a large drop of CPU usage depending on the video format and current frame-rate (the lower the framerate is the lower is the benefit while 'nosignal', grabber via kernel still takes its resource: bigger for uncompressed YUV smaller for MJPEG). |
With signal detection enabled, the instance is disabled and LEDs are turned off but the grabber continues to capture frames. An option to drop the frame rate and resolution in a no-signal state could save significant CPU at idle.
Pi 3 B+, HyperHDR 16.0.0.1 with a MicroSilicon MS2109 USB grabber using YUYV at 1280x720 with quarter frame mode and spare processing enabled. Testing frame rate cpu usage from uvcvideo while signal is OFF: 30 fps: 20%, 5 fps: 12%
If I also drop the resolution to the lowest supported, 640x480, CPU usage from uvcvideo drops to <5%.
Signal return is still detected immediately at 640x480/5fps
What problem does this feature solve?
Idle CPU usage
What does the proposed API look like?
n/a
How should this be implemented in your opinion?
When signal detection is checked, reveal an input to set a different frame rate and resolution from supported values when no signal is detected. Switch grabber to those settings before "disabling" instance.
Are you willing to work on this yourself?
Unfortunately I do not know C++. I attempted to solve this with a python daemon watching priorities from the API, but i couldn't find a reasonable/obvious way to manage grabber frame rate from there...
The text was updated successfully, but these errors were encountered: