Best scrcpy configuration for low-latency mobile gaming

One frame at 60 fps lasts 16.7 ms. Before a mirrored game shows you anything, that frame has to be captured, squeezed through a hardware encoder, pushed across USB or Wi-Fi, decoded on your PC and drawn. Your tap then makes the same trip backwards. Scrcpy’s stock defaults favour a clean picture over the shortest path.

This list is for people who mirror their own Android phone to a PC to play or test real-time games and want the lowest input lag scrcpy can give. It answers the reader question in scrcpy issue #4942: which bitrate, codec and buffer flags cut input lag for real-time use, and what gap is left compared with playing on the phone. Short version: use a cable, cap resolution and frame rate, leave the video buffer at zero, choose a hardware h264 encoder, and accept that you will still be behind native play.

I have no millisecond figures I’d put my name to, so there are none here. Measure your own phone: film your finger and the screen with a 240 fps slow-motion camera, once natively and once through scrcpy (one camera frame is about 4.2 ms), and count frames between the touch and the reaction.

how I picked

each pick names a real scrcpy flag or a specific hardware choice. “optimise your settings” is not a pick
it has to shorten or remove a stage in the path: capture, encode, transport, decode, render or input. settings that only sharpen the picture stayed out
the cost is stated, because every lever trades something: sharpness, audio, heat or compatibility
you can check it, with --print-fps in the console or the slow-motion test above
stock scrcpy only, from the official releases, no forks or paid wrappers. Defaults quoted here come from the scrcpy 3.x docs as of January 2026, and flag names move between releases, so run scrcpy --help on your build

the picks

Eight levers, in the order I’d try them.

Wired USB baseline

Start here, before touching a video flag. A cable takes Wi-Fi jitter, router queues and radio retransmits out of the path, and it costs nothing. Bandwidth isn’t the reason: USB 2.0’s 480 Mbit/s is far more than a 12 Mbit/s video stream needs, so a phone stuck at USB 2.0 speeds is fine.

What matters is a stable link. Use a data-capable cable, a port on the back of the PC rather than a hub, and check that adb devices says device and not unauthorized, which usually means the RSA key prompt went unanswered.

pro: removes Wi-Fi jitter, retransmits and interference from the path
pro: every other pick in this list assumes it
pro: costs nothing if you already own a cable
con: you are tethered, and a phone that charges while gaming runs warm, which throttles and adds lag of its own

Price: free, using a cable you already own. Link: what the adb client, server and daemon do

Resolution and frame-rate caps

The command is scrcpy --max-size=1600 --max-fps=60. --max-size limits the larger dimension and keeps the aspect ratio, so a 2400x1080 phone held sideways comes out at 1600x720. Fewer pixels means less work for the phone’s encoder and your PC’s decoder.

--max-fps caps the frames handed to the encoder, and the scrcpy docs call it officially supported from Android 10. On a 120 Hz phone running a game at 120, a 60 cap halves the encoder’s load at the price of a 16.7 ms step instead of 8.3 ms. Add --print-fps: if the rate sits under your cap, the encoder or your PC is the bottleneck, so lower the size before touching anything else.

pro: less encode and decode work per frame, so less chance of queueing
pro: a locked 60 gives steadier pacing than a rate that swings with encoder load
con: text and small HUD elements go soft at lower sizes
con: a 120 Hz phone loses half its frames on the mirror

Price: free. Link: scrcpy video docs

Bitrate matched to the link

The default is 8M. On a cable I’d start fast games at --video-bit-rate=12M, and on Wi-Fi drop to 6M. On a wire, bitrate alone doesn’t add latency. On Wi-Fi a scene change produces a burst of data, and the stream rides on TCP, so one late packet holds up everything behind it.

The second half is the mode. --video-codec-options=bitrate-mode=2 asks the encoder for constant bitrate (0 is constant quality, 1 is variable, 2 is constant, per Android’s MediaCodecInfo constants). That keeps burst size predictable, at some cost in busy scenes. Some encoders ignore it and a few refuse to start with it, so drop the option if scrcpy fails.

pro: smaller bursts mean shorter stalls when a packet is late
pro: over a cable there’s headroom to raise it for fast games
con: quality dips in busy scenes, since the encoder can’t borrow bits from quiet ones
con: support for the mode is patchy, so what works on one phone may do nothing on the next

Price: free. Link: best scrcpy settings to fix lag and stuttering

Hardware h264 encoder, chosen on purpose

Run scrcpy --list-encoders. Android names software encoders like c2.android.avc.encoder and vendor hardware ones like OMX.qcom.video.encoder.avc, and the names differ by chipmaker and Android version. Scrcpy takes the first encoder Android offers for the codec, which is normally hardware but not always. If yours picked software, force the hardware one with --video-encoder=<name>. A software encoder that can’t hold the frame budget queues frames, and queued frames are input lag.

I wouldn’t use h265 or av1 to chase latency. They shine when bandwidth is the problem, since they make smaller streams at similar quality, but they generally cost more to encode and decode, and AV1 hardware encoders are still uncommon on phones. h264 is the default and where I’d stay.

pro: keeps encoding on the phone’s video hardware instead of its CPU cores
pro: h264 has the widest encoder support and the cheapest decode on the PC
con: names are per phone, so this can’t be a copy-paste flag
con: some hardware encoders reject odd sizes or options and fail to start, and logcat is where you find out why

Price: free. Link: logcat guide: filter by app, tag and priority

Encoder priority and codec options

--video-codec-options hands key=value pairs to Android’s MediaFormat on the phone, integers by default. The one I try is priority=0, which asks the codec to run in real time (1 is best effort): --video-codec-options=priority=0. Read the Android reference below for what each key means before you paste anything from a forum.

One trap. low-latency looks like the obvious key, but the reference documents it as a decoder key, and the decoder in this chain is FFmpeg on your PC, not the phone. Check the reference for your Android version.

This is the pick with the weakest evidence. Keep it only if --print-fps or the slow-motion test shows a difference.

pro: one flag, easy to test and easy to remove
pro: asks for real-time scheduling, which is what you want here
con: the effect depends on the vendor encoder, so it may be zero
con: a bad key or value can stop the encoder starting

Price: free. Link: Android MediaFormat reference

Zero video buffer and a deliberate audio choice

Scrcpy’s video buffer defaults to 0 ms: no added delay, and frames are shown as soon as they’re decoded. The flag is --video-buffer on recent builds and --display-buffer on older ones. Raising it to 30 or 50 ms smooths jitter by adding that much delay, which is the wrong trade for gaming. Leave it alone.

Audio is where people leak latency without noticing. Forwarding needs Android 11 or later, --audio-buffer defaults to 50 ms and --audio-output-buffer to 5 ms. 50 ms is three frames at 60 fps, and it runs separately from the video path, so sound and picture can drift apart. Your options: --no-audio and use the phone’s own speaker, --audio-buffer=20 and accept crackles if your PC underruns, or keep the default for games where timing isn’t critical. For rhythm games I’d stay native.

pro: no artificial delay added to the video
pro: --no-audio also drops audio capture and encode work
con: zero buffer turns Wi-Fi jitter into visible stutter
con: --no-audio puts game sound back on the phone, and a small audio buffer can crackle

Price: free. Link: scrcpy lag and stutter settings

HID input: mouse, keyboard and gamepad

By default scrcpy injects mouse and keyboard events through Android’s input system from a process on the phone. What it can’t do is give you more than one finger. A mouse is one pointer, so holding a virtual stick while tapping skill buttons doesn’t work.

--mouse=uhid and --keyboard=uhid present a virtual HID device to the phone (aoa is the USB-only alternative), and recent 3.x builds forward a physical pad with --gamepad=uhid. In a game with controller support, a real pad fixes the multi-touch problem properly. Don’t script taps with adb shell input for live play: each call starts a fresh process on the phone, and the input tap, swipe and keyevent guide shows where it does fit.

pro: a real gamepad covers what one mouse pointer can’t, in games that support controllers
pro: input rides scrcpy’s own socket, with none of adb shell input’s per-call process start
con: many touch-first games ignore HID devices entirely
con: scrcpy has no on-screen key mapping. QtScrcpy has one, but it’s a separate program and I haven’t tested it for lag

Price: free, plus a gamepad if you don’t own one. Link: Android RPA with adb and uiautomator2, for when you want scripted input rather than live play

Wireless fallback, tuned

Run adb tcpip 5555 once over the cable, then scrcpy --tcpip=192.168.1.50 with your phone’s address. On Android 11 and later you can skip the cable with Wireless debugging in Developer options, adb pair and adb connect. Then change three things: bitrate to 6M, --max-size=1280, --max-fps=60. Use 5 GHz or 6 GHz, keep the phone in line of sight of the router, and put the PC on ethernet.

Scrcpy rides TCP, so one lost packet stalls the stream until it’s resent, and you see a freeze then a jump. That’s fine for turn-based, idle and casual games and for testing. Anything where one missed input decides the round, I wouldn’t do wirelessly.

pro: no cable, so the phone can sit in your hands or on a stand
pro: same flag set as wired, only bitrate and size change
pro: on Android 11 and later pairing needs no USB at all
con: jitter and retransmit stalls that no flag fully hides
con: neighbours’ networks and other devices are outside your control

Price: free, assuming a router you already own. Link: adb authorization and RSA keys explained

comparison table

pick	price	primary strength	primary weakness
Wired USB baseline	free, cable you own	removes Wi-Fi jitter	tethered, phone warms while charging
Resolution and frame-rate caps	free	less encode and decode load	softer image, half the frames on 120 Hz
Bitrate matched to the link	free	shorter stalls on Wi-Fi	quality dips in busy scenes
Hardware h264 encoder	free	keeps encoding on video hardware	names differ per phone
Encoder priority and codec options	free	asks for real-time scheduling	may do nothing on some encoders
Zero video buffer and audio choice	free	no added video delay	Wi-Fi jitter shows as stutter
HID input	free, gamepad extra	real gamepad in supporting games	many touch games ignore HID
Wireless fallback	free	no cable	retransmit stalls

how to choose

Change one flag at a time. Start with the wired baseline plus the caps from the verdict, run --print-fps, and only move on once the frame rate holds your cap. If it doesn’t, lower --max-size before touching bitrate, encoder or options, because the encoder or your PC is the bottleneck and later picks won’t fix that. Judge changes with the slow-motion camera, not by feel. Expecting a fix makes anything feel faster.

Mirroring adds capture, encode, transport, decode and render stages that native play doesn’t have. You can shorten that chain but not delete it. What stays worse: the picture’s return trip, audio on its own 50 ms default buffer, a single touch point unless you use a gamepad, and extra heat from a phone that’s gaming and encoding at once. I’d keep twitch shooters, rhythm games and anything ranked on the phone. Turn-based, strategy, idle games and testing sessions mirror fine.

Use this on phones you own or are cleared to test. Some games ban mirroring or input tools in their terms, so read them before you play anything ranked. If one app shows a black window while everything else mirrors fine, that app is blocking screen capture on purpose. I don’t cover getting around either.

If the trouble is that you don’t have the phone at all, say you need a real Singapore handset with a Singapore mobile IP to see how a game behaves there, cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. It’s Singapore-only, and it isn’t a low-latency gaming route: you drive it through a browser and I have no latency figures for it. There’s no self-service adb either. adb and Appium reach a rented phone only through a WireGuard tunnel we set up on request (email [email protected]), and scrcpy has nothing to connect to until that tunnel is up. Running a shelf of your own phones? See best open source android device farm tools, and the rest of the adb write-ups are on the blog index.

verdict / top pick

Top pick: the wired baseline with the size and frame-rate caps. Those two do the most for the least, and every other pick builds on them. This is where I’d start:

scrcpy --max-size=1600 --max-fps=60 --video-bit-rate=12M --no-audio

Drop --no-audio if you need the sound on the PC and can live with the 50 ms default buffer. Then, one at a time, try --video-codec-options=priority=0, and a hardware --video-encoder if --list-encoders shows your default is software. Keep each only if --print-fps or the slow-motion test says it helped. On Wi-Fi, use the same line with --tcpip=<phone ip>, --max-size=1280 and --video-bit-rate=6M.

What you can’t tune away is the pipeline itself. Scrcpy is good enough for testing, strategy and casual play, and for anything that hinges on a single tap, native is still faster.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-24.