Environment
- OS / distro + version: Ubuntu 26.04.1 LTS (Resolute Raccoon)
- Desktop / compositor: KDE Plasma 6.6.6 / KWin 6.6.6 / Wayland
- evdi version: N/A — using native KWin Virtual capture backend
- GStreamer version:
- Rust toolchain: N/A — installed from the release
.deb
- Orbiscreen version: v0.25.9
- GPU / encoder: AMD / VA-API (
vah264enc)
- Android device: Astra 9" tablet
Steps to Reproduce
- Start Orbiscreen and connect the Android tablet.
- Connect using either Wi-Fi or USB Direct (AOA).
- Move a window continuously around the virtual display for several seconds.
- Stop moving the window and observe the Android display.
I initially tested at 1920x1080 @ 60 Hz / 8000 kbps. I have also reproduced the problem after reducing the refresh rate, resolution, and bitrate.
Expected Behaviour
For an interactive secondary display, the stream should prioritize showing the most recent frame.
If the encoder, transport, decoder, or renderer cannot keep up in real time, it might be desirable for the stale frames to be dropped so that the client catches up to the current desktop state.
Some dropped frames or temporarily choppy motion would be preferable to accumulating seconds of latency.
Actual Behaviour
The Android client can accumulate multiple seconds of latency.
this does not look like ordinary low frame rate or choppy rendering:
- I can continuously move a window around the virtual display.
- After I stop moving it on the host, the Android client continues reproducing the previous movement for seconds.
- The client eventually catches up to the final position.
- The amount of delay is unstable and appears to grow/shrink during use.
In other words, the client appears to be processing stale frames rather than dropping them when it falls behind.
This happens over both:
USB Direct is now connecting successfully with v0.25.9 following the fix in #76, but the same accumulated-latency behaviour occurs there as over Wi-Fi.
Reducing the workload improves the situation somewhat, but does not eliminate the fundamental behaviour. I tested lower refresh rates/resolutions, including 30 Hz, and the client can still replay frames from seconds earlier.
I also tested reducing:
[encode]
bitrate_kbps = 8000
to:
[encode]
bitrate_kbps = 3000
at 1920x1080 @ 30 Hz. This did not materially fix the accumulated latency.
Environment
.debvah264enc)Steps to Reproduce
I initially tested at 1920x1080 @ 60 Hz / 8000 kbps. I have also reproduced the problem after reducing the refresh rate, resolution, and bitrate.
Expected Behaviour
For an interactive secondary display, the stream should prioritize showing the most recent frame.
If the encoder, transport, decoder, or renderer cannot keep up in real time, it might be desirable for the stale frames to be dropped so that the client catches up to the current desktop state.
Some dropped frames or temporarily choppy motion would be preferable to accumulating seconds of latency.
Actual Behaviour
The Android client can accumulate multiple seconds of latency.
this does not look like ordinary low frame rate or choppy rendering:
In other words, the client appears to be processing stale frames rather than dropping them when it falls behind.
This happens over both:
USB Direct is now connecting successfully with v0.25.9 following the fix in #76, but the same accumulated-latency behaviour occurs there as over Wi-Fi.
Reducing the workload improves the situation somewhat, but does not eliminate the fundamental behaviour. I tested lower refresh rates/resolutions, including 30 Hz, and the client can still replay frames from seconds earlier.
I also tested reducing:
to:
at 1920x1080 @ 30 Hz. This did not materially fix the accumulated latency.