Latency creep with dual Comet-RM1 POE streams on Raspberry Pi 5 / ustreamerparameter issues

We are developing a KVM control dashboard that requires interfacing with two video
streams from Comet-RM1 POE devices simultaneously through a Raspberry Pi 5. During
testing, we have encountered significant latency creep when processing both streams
concurrently.

When a single stream is active, performance is excellent with minimal latency. However,
introducing a second stream (either from the same Comet or a second unit) causes a
significant increase in system load on the Pi. While the image quality remains stable, the
latency steadily increases over time until the video is several thousand milliseconds
behind, rendering the interface unusable. We are actively looking for ways to decrease
the processing load on the Pi to maintain real-time performance.

In our attempts to optimize this, we modified /etc/kvmd/main.yaml. On the standard
Comet-RM1, setting --vi-buffer-num=1 successfully reduced latency under load, with
an acceptable trade-off in image quality. However, on the Comet-RM1 POE version, this
setting does not appear to have the same effect. While the argument seems to pass to
ustreamer successfully, the video behavior remains unchanged.

Notably, there is a stark difference in CPU overhead between the two models. When
processing two streams from the standard non-POE Comet, we observe approximately
50% utilization across all Pi cores via htop. However, when pulling from the POE Comet,
the load spikes to over 85% on every core. Additionally, the --desired-fps flag in
main.yaml appears to have no effect on the actual FPS output from the Comet, which
would otherwise be a viable way for us to reduce the load.

We would appreciate clarification on whether --vi-buffer-num=1 and --desiredfps are supported or applied differently on the POE variant. Furthermore, if there are
alternative ustreamer parameters, configuration adjustments, or general
recommendations to reduce the load on the Pi 5 when handling dual streams, any
guidance would be greatly appreciated.

--vi-buffer-num=1 reducing this parameter will cause input frame drops, making it impossible to maintain a stable input of 60 frames.

--desired-fps has been deprecated. We do not allow modifying the frame rate, not because it cannot be achieved, but because we deem it unnecessary. PIKVM added this parameter due to the encoding performance limitations of the Raspberry Pi, but we can smoothly encode at 60 frames per second or even higher.

I'm not quite clear about your usage scenario. Are you trying to use the Raspberry Pi 5 as a control terminal to manage two KVMs simultaneously, and then encountering issues with the Raspberry Pi 5's poor decoding capability?

Thanks for the response.

--vi-buffer-num=1 reducing this parameter will cause input frame drops, making it impossible to maintain a stable input of 60 frames.

Keeping an input of 60 frames is not a priority for us. Frame rates of around 20-30 are acceptable for our use case.

Are you trying to use the Raspberry Pi 5 as a control terminal to manage two KVMs simultaneously, and then encountering issues with the Raspberry Pi 5's poor decoding capability?

Yes this is pretty much the scenario.

Since there is no way to adjust the output FPS, the simplest method might be to create an EDID with 30 Hz or even 20 Hz, or directly modify the output frame rate in the graphics card of the controlled computer.

We have noticed an improvement in latency setting an edid for 20hz and vi-buffer-num=3 on the POE comet.
Is there any reason why setting vi-buffer-num=1 on the POE comet results in “No HDMI signal detected” while doing the same on the non POE comet works fine?

They use different chips, and there might be some differences in encoding processing.