Redirecting scrcpy's video stream into OBS or another app

this one is about me, a Singapore-based operator who spends a lot of time with Android phones plugged into a desktop. i wanted to put a phone screen into a live scene in OBS, and later into a call app, without the scrcpy window sitting on top of everything and without a pile of moving parts. the question comes up often enough that it has a long-running thread on the scrcpy tracker (issue 1073): can you redirect scrcpy’s video stream into OBS or some other app instead of just watching it in scrcpy’s own window?

the short answer, as of October 2026: it depends on your desktop OS. on Linux there is a proper virtual camera route built into scrcpy. on Windows and macOS there is no equivalent, so you either capture the scrcpy window or you record to a file. --record is for files, not for live feeds, and i learned that the slow way. for most live use on Windows, window capture in OBS is what i ended up keeping.

i am not going to give you latency or fps benchmarks, because i did not run a controlled test and i don’t want to invent one. what follows is what i set up, what behaved badly, and how i would decide between the options if i were starting again today.

the setup

the stack was deliberately boring.

host: a Windows 10 desktop, and later a Linux box for the virtual camera test
phone: one spare Android phone, USB debugging on, connected by a data-capable USB cable
scrcpy: the current release from the official Genymobile repo, run from the command line
OBS Studio: the stock build from obsproject.com
Linux only: the v4l2loopback kernel module, which scrcpy’s --v4l2-sink option writes into

cost: scrcpy, OBS and v4l2loopback are all free and open source. the only money was the cable and the phone i already owned. if the phone is the thing you don’t have, there is a section further down on that.

the three routes i compared:

window capture: run scrcpy normally, add the scrcpy window as a Window Capture source in OBS
file route: run scrcpy --record=file.mkv and have OBS or another app read the file
virtual camera: on Linux, scrcpy --v4l2-sink=/dev/videoN --no-playback, then pick that device as a webcam in OBS, a browser, Zoom or whatever else

scrcpy’s own documentation covers the last two in its recording doc and its v4l2 doc. read those before you trust anything i say about flags, because options get renamed between releases. --no-display became --no-playback in newer versions, for example, so if a flag in an old forum post errors out, check the version first.

one prerequisite that trips people before any of this matters: scrcpy has to see the phone. if the toggle is greyed out, see fixing a greyed-out USB debugging toggle on Android. if you’re on a Mac and nothing opens, see fixing scrcpy that won’t connect or open on macOS.

what worked

window capture, with the window cleaned up

this is the route i use on Windows. you launch scrcpy with a few options so the window is a clean rectangle that OBS can grab:

scrcpy --window-borderless --window-title="phone1" --max-size=1280 --max-fps=30

then in OBS: add a Window Capture source, pick the window titled phone1, and crop or scale it in the scene. a fixed --window-title matters more than it sounds. OBS matches windows by title and executable, so if the title changes between launches, the source goes blank and you hunt for it again. naming each instance fixes that, and it is also how i keep several phones apart when more than one is open.

--max-size and --max-fps are there to lower the load on the encoder in the phone and the decoder on the PC. i capped to 30 fps because my scene output was 30 fps anyway, and there is no point decoding frames you never show. that is a reasoning choice, not a measured gain.

choosing the right OBS capture method

on my Windows machine the first Window Capture attempt showed a black rectangle. scrcpy renders through SDL with GPU acceleration, and some capture methods in OBS cannot see that surface. switching the source’s capture method (the OBS knowledge base page on the Window Capture source describes the available methods) to the Windows 10 one fixed it for me. if you hit a black source, try the other capture methods before touching scrcpy at all. it is almost always an OBS capture setting, not a scrcpy bug.

the v4l2 virtual camera on Linux

this is the closest thing to a real answer to the issue 1073 question. with v4l2loopback loaded, scrcpy writes decoded frames into a fake webcam device. OBS, a browser and a call app all see it as an ordinary camera. i used it with --no-playback so there was no scrcpy window at all, just the camera device.

what i liked: no window to keep unobstructed, no capture method guessing, and any app that accepts a webcam can use it. i tried it in OBS and in a browser tab that asks for camera access, and both listed the device.

what to know before you commit: it is Linux only, and you need to load the kernel module with root. i am not giving you the exact modprobe line, because the right options depend on your distro and kernel, and the scrcpy v4l2 doc has the current guidance.

recording alongside a live window

--record=session.mkv works well in parallel with a live window. i use it as a safety copy: scrcpy shows the phone, OBS captures the window for the stream, and the mkv is a clean untouched copy with no OBS overlays on it. mkv is a sensible container here because a crash or a yanked cable leaves a playable file, which is the reason scrcpy’s recording doc leans toward it (check the doc for the formats it supports in your version).

one instance per phone, named

for more than one phone i run one scrcpy process per device with -s <serial> and a unique --window-title. one process per phone, one OBS source per window. that is simple to reason about. how many you can run depends on the host, and i wrote up where the limits show up in host limits for running many Android phones.

what broke

the “pipe –record into OBS” idea

this was my first plan and it was the wrong one. the appeal is obvious: scrcpy already produces an encoded stream, so why decode it, draw it in a window, and capture the window again?

what went wrong:

--record writes a file in a container. it is built to produce a finished recording, not a stream a second app can attach to
OBS’s Media Source can open a local file, but pointing it at a file that is still being written is not a dependable live feed. for me it showed a stale frame or stopped, and there is no clean way to tell it to follow the growing end of the file
i could not find a documented way to make scrcpy emit the recording as a live stream to another process on stdout, so i stopped treating it as an option

the workaround was to stop forcing it. if you want a recording, record. if you want a live source, use window capture, or the v4l2 sink on Linux. i spent an evening trying to bend the file route into a live feed and got nothing i would put in front of an audience.

the black or frozen window capture

two separate causes, same symptom:

black source: the capture method issue above. fix by changing the OBS capture method
frozen source after minimising: OBS cannot capture a minimised window on most methods, and scrcpy’s window is no different. the fix is boring, keep the window on screen, or use --always-on-top so something else doesn’t cover it. covered windows are fine with some capture methods and not with others, so test with your own setup

input not working while the stream is live

on one Oppo phone the video was fine but keyboard and mouse input did nothing, which matters if you are demoing something on the phone. that is a separate phone-side permission issue, and the fix is in fixing scrcpy keyboard and mouse input that doesn’t work on Oppo phones. if you only need to display the screen, you can ignore it, since the video path doesn’t depend on input.

the numbers

this is the section where i’m supposed to give ROI and scaling ratios. for a tooling choice like this there is no revenue to measure, so here is what i can honestly say.

software cost: 0 for scrcpy, OBS and v4l2loopback. all three are open source
hardware cost: one data-capable USB cable if you don’t have one. the phone is whatever you already own
setup time: window capture took me a few minutes once i knew about the capture method issue. the failed file-piping detour cost me about an evening, and that is the number that matters here
processes: one scrcpy process per phone, so the scaling unit is one window (or one v4l2 device) per phone
stream defaults: scrcpy’s default video bit rate is 8 Mbps per its documentation. lowering it with --video-bit-rate is a lever when USB or wireless links struggle, but i have no measured before and after to give you
latency: i have no measured figure, and i would not trust anyone’s number that isn’t from their own cable, phone and PC. if you need a number, film the phone and a stopwatch app with a second camera, then count the frame difference yourself

what i can say is the ratio between routes in effort: window capture is the least work on Windows and macOS, v4l2 is the least work on Linux once the module is loaded, and the file route is the most work for the worst result as a live source.

lessons

decide first whether you want a live source or a recording. --record is for the second one. mixing them up cost me the most time
on Linux, use --v4l2-sink with --no-playback if you want a webcam-style device. it is the only route here that behaves like a real redirect
on Windows and macOS, window capture is the practical answer. clean it up with --window-borderless, a fixed --window-title and a frame rate cap that matches your scene
black source in OBS means try another capture method before blaming scrcpy
keep the recording running alongside the live window if the footage matters. a clean mkv copy is cheap insurance
re-read the flags against your scrcpy version. option names move between releases, and old forum posts are full of dead flags

if you are comparing the broader tooling around phones on a desk, i keep related notes on the blog index, including how i choose between UI test frameworks in Maestro vs Appium on Android.

would I do it again

yes, with the detour removed. i would start with window capture on Windows, accept that it is a capture of a window and not a true redirect, and move on. i would only go to the virtual camera route if i were on Linux or needed the phone to appear as a webcam in a call app, because that is the one case where window capture is clumsy.

i would not try the file route as a live source again. if someone shows a clean, documented way to follow a growing recording in OBS, i would test it, but i would not build on it until then.

one more case that sent me looking for another answer: when you don’t have a phone on the desk at all, or you need one with a Singapore mobile connection for what you’re testing. cloudf.one rents real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. it is Singapore only. i should be precise about the limit, because it matters for this article: there is no self-service adb on those phones. adb and scrcpy-style access only work through a WireGuard tunnel that we set up on request (email [email protected]). so if your plan depends on piping scrcpy into OBS from a rented phone, that is a request to us first, not something you can switch on yourself. if you only need to see and use the phone, the browser control is enough and none of this applies.

as always, only point scrcpy at phones you own or are authorised to test. showing a screen on a stream is a good reason to check what is visible on it first, notifications and saved logins included.

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-10-10.