High latency with scrcpy (~35–70ms) in cloud Android setups

[maddox05]

Hi! I’m building an Android cloud-gaming platform.

Repo:
https://github.com/maddox05/android-cloud-gaming

I’ve been experimenting with an Android stack built on ReDroid (Docker) combined with scrcpy server to extract frames and handle input forwarding.

GPU passthrough in ReDroid is still a separate issue that I’m debugging, but my main question is about scrcpy latency.

---

Observed behavior

Even with hardware encoding enabled, I consistently see an additional ~35–70ms of latency (given the docs) introduced by scrcpy itself (measured from input → frame update). This is on top of network RTT.

For cloud gaming, this becomes a bottleneck:

• Platforms like GeForce NOW advertise ~20–30ms end-to-end RTT
• With scrcpy, I’m already adding ~35ms before transport

---

Questions

1. Is this latency inherent to scrcpy’s architecture?

   • Is it primarily due to how frames are captured (SurfaceFlinger / MediaProjection)?
   • Or due to buffering, threading, or synchronization in the server pipeline?

2. Is scrcpy optimized for low-latency streaming, or more for reliability/debugging?
   My understanding is that scrcpy prioritizes stability and compatibility rather than absolute minimum latency?

3. Are there known ways to reduce this latency further?
   For example:

   • Alternative capture paths (bypassing SurfaceFlinger?)
   • Different encoder / buffer settings
   • Reducing frame queue depth or synchronization points

4. Would a custom “in-house” solution be required to go lower?
   If targeting sub-20ms:

   • Do most cloud-gaming platforms avoid SurfaceFlinger entirely? (now.gg cloudmoon)
   • Are they hooking closer to the GPU / HWComposer layer or using vendor-specific paths?

---

Context

I’m trying to understand whether:

• scrcpy can realistically be pushed closer to cloud-gaming-grade latency, or
• it’s fundamentally the wrong tool for this use case and better suited for debugging/mirroring

Any architectural insight or pointers would be hugely appreciated.

Thanks for the great work on scrcpy 🙏

• Maddox

[rom1v]

Probably due to missing hardware encoding. What's the result of scrcpy --list-encoders on that Android VM?

[maddox05]

scrcpy 3.3.3 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO:     --> (tcpip)  localhost:5555                  device  redroid12_arm64_only
/opt/homebrew/Cellar/scrcpy/3.3.3/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 321.0 MB/s (90164 bytes in 0.000s)
[server] INFO: Device: [redroid] redroid redroid12_arm64_only (Android 12)
[server] INFO: List of video encoders:
    --video-codec=h264 --video-encoder=c2.android.avc.encoder         (sw)
    --video-codec=h264 --video-encoder=OMX.google.h264.encoder        (sw) (alias for c2.android.avc.encoder)
    --video-codec=h265 --video-encoder=c2.android.hevc.encoder        (sw)
[server] INFO: List of audio encoders:
    --audio-codec=opus --audio-encoder=c2.android.opus.encoder        (sw)
    --audio-codec=aac --audio-encoder=c2.android.aac.encoder          (sw)
    --audio-codec=aac --audio-encoder=OMX.google.aac.encoder          (sw) (alias for c2.android.aac.encoder)
    --audio-codec=flac --audio-encoder=c2.android.flac.encoder        (sw)
    --audio-codec=flac --audio-encoder=OMX.google.flac.encoder        (sw) (alias for c2.android.flac.encoder)

I was under the impression that 35-70ms was the best you could get (given the docs) currently im running only on a cpu so i expect much worse, but even running it on a gpu, its a ton faster, but still delayed.

hardware encoding requires a gpu, and I dont have one of this system so this makes sense, but my question was more of why is their still a delay on a gpu of 35-70ms and what ways can that be combatted?