Add receiver diagnostics and remote PicCap handover

This commit is contained in:
matze19999 committed 2026-10-06 18:35:56 +02:00
1 parent ae01879d45
commit 42aeaf56ea
19 files changed
+322 -50

No files matched your search

+10
View File
@@ -79,3 +79,13 @@ HyperHDR 22's `HyperHdrInstance::setColor` registers `ledColors[0]` as a solid c
For HyperHDR selection, 0.8.1 sends an RGB JSON image generated from the calibrated histogram edge samples on a cached 160x90 geometry. The receiver samples the synthetic plane using its LED rectangles and image processing. Hyperion retains per-LED color-array output. No TV video pixels are captured or transmitted by the generated plane. Original saturation/brightness gains remain 1.0. Receiver configuration is not modified.
On the G4 with HyperHDR 22.0.0, a temporary spatial test input produced 120 unique colors for 120 LEDs and was cleared. Exact RGB/base64, image command and spatial geometry tests passed on ARM. After installation of 0.8.1, the real histogram source was visible as IMAGE at priority 149. Eleven LED-stream samples from actual playback contained 87-100 unique colors across the 120 LEDs, confirming spatial output rather than a solid color. This plane has approximate calibrated spatial resolution, not full video-frame detail; HyperHDR's configured mapping and calibration affect the output.
## Receiver diagnostics and remote PicCap (0.9.0)
The own service exposes a nonblocking read-only JSON connection test, separate from streaming/capture. The UI reports connection/layout/authentication results and capture/retry diagnostics without exposing saved API tokens. Auto PicCap now reads settings and updates only address, port and unix-socket through its existing API when required. Unlike older versions, endpoint configuration is saved by PicCap; other settings and its autostart preference are preserved. PicCap setSettings restarts its capture, so HyperDRM releases VT first and checks status before treating the source as active. Remote IPv6 keeps histogram capture because the tested PicCap network client is IPv4-only.
ARM tests on the G4 passed connection diagnostics, fragmented replies, invalid layout, rejected token, connection refusal/timeout, receiver setting persistence and remote PicCap controller transitions. The app receiver-field and remote-navigation tests passed. The installed local HyperHDR JSON test validated 120 LEDs in 224 ms; a remote relay with synthetic authentication and fragmented responses validated the same layout in 625 ms. The unprotected test video used PicCap through the PC address and custom FlatBuffer port, with connected:true, videoRunning:true and actual FlatBuffer bytes received by the relay. PicCap retained all non-endpoint settings, including autostart:false. These relays test a remote transport to the actual local HyperHDR instance, not a separately installed remote HyperHDR instance.
Switching the user playback back to DRM stopped PicCap automatically and resumed histogram output through the remote JSON relay. Seven actual HyperHDR LED-stream samples contained 89-91 distinct colors for 120 LEDs, with no all-black sample. Both test endpoints were restored to local defaults and the synthetic token was removed.
The remote FlatBuffer relay received over 411 MB from PicCap during the test session. The final port validation also rejects explicit JSON null while retaining the default for older preferences without the new field.