Using scrcpy to turn an Android phone into a webcam

This case study is about me, a Singapore-based operator who spends a few hours a week on video calls and recording screen walkthroughs. my laptop webcam is a 720p fixed-focus sensor that makes everyone look like a security camera still. I also had a spare Android phone in a drawer with a camera far better than anything I would pay for in a standalone webcam. the goal was simple: get that phone’s camera into Teams, Zoom, Google Meet and OBS as a normal webcam source, over a USB cable, without installing a random webcam app on the phone.

the question that sends a lot of people to this topic is scrcpy issue #776: can scrcpy act as a webcam? the direct answer is half yes and half no. scrcpy itself does not register a camera device with Windows or macOS. it gets video from the phone (screen or camera) and shows it in a window, or on Linux pushes it into a v4l2 device. to make other apps see it as a webcam you need a virtual camera layer on top. which layer depends on your operating system, and that is most of what this article covers.

the headline result: it works, it is free, and the picture is clearly better than my built-in webcam. it is also more fiddly than a dedicated webcam, and I hit three real problems along the way. everything below is what I saw on my own desk, and I say where I did not measure something.

the setup

the stack, in the order the video travels:

phone: a spare Android phone running Android 12 or newer. this matters because scrcpy’s camera capture needs Android 12 or higher.
cable: a decent USB data cable, not a charge-only one. usb debugging has to be on and the computer authorised.
scrcpy: a current release from the official GitHub repo. camera mirroring was added in the 2.x line, so an old package from a distro repo or a stale Chocolatey/Scoop install may not have it. check with scrcpy --version.
adb: bundled with the scrcpy release zip on Windows. if you already run your own platform-tools, make sure there is only one adb server on the machine. see Google’s adb documentation for the basics.
virtual camera layer: OBS Studio’s built-in virtual camera on Windows and macOS, or v4l2loopback on Linux.
consumer app: Teams, Zoom, Meet or OBS itself.

my main machine is Windows 10, so the path I used daily was scrcpy to OBS to OBS Virtual Camera to the call app. I also tested the Linux path on a second machine because the v4l2 route is the closest thing scrcpy has to a native webcam mode.

costs, roughly, as of October 2026:

phone: S$0, because I already owned it. a used mid-range phone from Carousell is the realistic cost if you do not have one, and prices swing a lot so I will not quote a number.
cable: about S$10 for a decent one.
tripod or phone clamp: about S$15 to S$25 for a small desktop one.
software: S$0. scrcpy is Apache 2.0, OBS Studio is free and open source, v4l2loopback is free.

scale is one phone, one laptop, one user. for several phones, each camera stream needs its own scrcpy instance and virtual device.

the basic commands. first confirm the phone is visible:

adb devices

then list what the phone’s cameras offer:

scrcpy --list-cameras
scrcpy --list-camera-sizes

then start a camera session instead of a screen mirror:

scrcpy --video-source=camera --camera-facing=back --camera-size=1920x1080 --no-audio

the official scrcpy camera documentation lists the flags for facing, size, frame rate and aspect ratio. size and fps availability depend on what the phone’s camera hardware reports, so use the list commands rather than guessing.

that gives you a scrcpy window showing the camera. on Windows that window is the thing OBS captures.

what worked

OBS window capture plus virtual camera on Windows

this is the path that works on the platform most people use. in OBS I added a Window Capture source pointing at the scrcpy window, cropped away the border, scaled to the canvas, and clicked Start Virtual Camera. OBS documents the feature in its virtual camera guide. in Teams and Zoom the device then appears as “OBS Virtual Camera”.

the useful detail is order of operations. start scrcpy first, then OBS, then the virtual camera, then open the call app. several apps read the device list once at launch, so if you start the virtual camera after the call app it may not appear until a restart. if you already read my piece on redirecting scrcpy’s video stream into OBS or another app, this is the same chain with the camera as the source instead of the screen.

camera mode instead of screen mirroring

my first attempt was lazy. I opened the phone’s stock camera app, mirrored the screen with scrcpy, and captured that. it works, but you get the camera app’s buttons in the frame, the screen has to stay on, and you are capturing a preview that has already been scaled for the phone display.

--video-source=camera is cleaner. scrcpy opens the camera directly, so there is no UI to crop out and the phone screen can stay dark. you pick the resolution from the list the phone reports. I settled on 1920x1080 at 30 fps because it was a good balance for calls.

the Linux v4l2 route

on Linux, scrcpy can write straight into a v4l2 loopback device, and this is the nearest thing to the “scrcpy as webcam” answer people want in issue #776. after loading v4l2loopback and finding the device number, the command looks like this:

scrcpy --video-source=camera --camera-facing=back --v4l2-sink=/dev/video2 --no-playback --no-audio

the scrcpy v4l2 documentation covers loading the module and the flags. browsers and call apps then see /dev/video2 as a regular camera with no OBS in the middle. the catch is that it is Linux only. scrcpy has no equivalent sink on Windows.

a fixed mount and manual exposure habits

this is not a scrcpy trick, but it made the biggest quality difference. a cheap clamp at the top of the monitor, the phone in landscape, and the window light coming from the side rather than behind me.

switching cameras without touching the phone

because the camera is chosen on the command line, switching from the back camera (the better sensor on most phones) to the front camera is a flag change. I keep two small batch files, one for back and one for front, and a third for a wider lens if the phone exposes one in --list-cameras.

what broke

the camera was not detected, or scrcpy refused to start the camera

first failure: scrcpy errored out on camera capture while screen mirroring worked fine. there were two causes across two phones.

the Android version was below 12. camera capture needs Android 12 or newer, per the scrcpy docs. nothing to fix other than using a newer phone.
the scrcpy build was old. a package manager copy predating camera support just ignores or rejects the flags. fix: download the current release from GitHub, run scrcpy --version, and check the version before debugging anything else.

the virtual camera showed up black or vanished in the call app

second failure: OBS showed the picture fine but Teams showed a black square, and on another day Zoom did not list the device at all.

the fixes, in the order I would try them:

start order: scrcpy, then OBS, then Start Virtual Camera, then the call app. restart the call app if you broke the order.
one consumer at a time: when two apps both held the virtual camera, the second one got black. close the app you are not using.
window capture method: on Windows, OBS Window Capture occasionally returned a black frame for the scrcpy window. switching the capture method in the source properties, or using Display Capture on a dedicated monitor region, fixed it. I do not know the exact driver trigger, so treat this as a workaround and not an explanation.
browser apps: Chrome and Edge remember per-site camera choices. if Meet is stuck on the laptop camera, pick OBS Virtual Camera in the site settings.

lag, drift and the usb cable

third failure: video stayed in sync with my face but the audio from the laptop microphone drifted by a visible amount in one long call. scrcpy’s video path adds some delay, the laptop mic adds none, so the lips look late. I did not measure the delay with a proper tool, so I will not give you a millisecond figure. what I did was add a video delay in OBS (Video Delay filter) and nudged it until the mouth and the sound lined up by eye, then reused that value.

there is a cleaner option if you want the phone’s microphone too, and I covered the method in using an Android phone as a PC microphone through scrcpy. the audio then travels the same path as the video, which tends to keep them closer together than mixing a laptop mic with a phone camera.

the cable also bit me once. a charge-heavy cable that only half worked caused random disconnects mid-call, and scrcpy simply closed. swapping to a short data-rated cable ended it. if scrcpy dies at random, change the cable before you change anything else.

the numbers

this is a personal tooling project, so there is no revenue, no CAC and no ROI in the business sense, and I would be making it up if I gave you any. here is what I can state honestly.

cash outlay: about S$25 to S$35 for a cable and a clamp, on top of a phone I already had. software was free.
time to first working call: roughly an afternoon, most of it spent on the black-frame problem and finding a current scrcpy build.
time to start a session now: under a minute using a batch file that launches scrcpy, then I open OBS and click Start Virtual Camera. I have not timed it with a stopwatch.
phones in use: 1. scaling to two cameras means two scrcpy windows, two OBS sources and, on Linux, two loopback devices. I tried two briefly and the laptop fans made themselves known, so I went back to one.
picture quality: clearly better to my eye than the built-in 720p webcam, especially in low light and in how skin tones look. that is a subjective comparison, not a test result.
compared with buying hardware: I did not buy a dedicated webcam, so I have no head-to-head. the phone path costs less up front but more in setup effort, and more can fail.

a caution on resources: scrcpy decoding, OBS compositing, the virtual camera and a video call encoder all run on the same machine. if you are on an older dual-core machine, test before you rely on it for something important.

lessons

check the Android version first. camera capture needs Android 12 or newer, so a phone that is fine for screen mirroring may be useless for this. test with scrcpy --list-cameras before you buy a clamp.
check the scrcpy version second. old packaged copies silently lack newer flags. use the official release and confirm with --version.
on Windows and macOS, plan on OBS Virtual Camera. scrcpy’s own v4l2 sink is Linux only, so the virtual camera layer is a separate piece of software you have to run.
on Linux, use the v4l2 sink and skip OBS if you do not need scenes. it is one less process and one less thing to crash.
fix the start order and write it into a batch file. scrcpy, then OBS, then the virtual camera, then the call app. that one habit removed most of my black-frame problems.
treat sync as something you tune by eye. add an OBS video delay until audio and lips line up, or move the audio onto the phone as well.
use the phone for camera work only on devices you own. if you are testing apps across several handsets, the rules in root vs non-root Android automation still apply: scrcpy needs no root for any of this. you can browse everything else I have written in the blog index.

would I do it again

yes, with a clear idea of who it suits. if you already own a spare phone running Android 12 or newer and you are comfortable in a terminal and OBS, this is a good use of hardware that would otherwise sit in a drawer. you get a better picture than most laptop cameras for roughly the cost of a cable and a clamp.

I would not recommend it to someone who just wants to plug something in and have a call in ten seconds. the chain has five links (phone, cable, scrcpy, OBS, call app) and any one of them can fail on a bad morning. a dedicated webcam has one link. for a high-stakes interview or a client presentation I still check the whole chain ten minutes early, and I keep the laptop webcam as the fallback in the device list.

on Linux I would use it with no hesitation, because the v4l2 sink makes the answer to issue #776 a one-line command. on Windows I would still do it, but I would accept that OBS is part of the deal. if scrcpy ever ships a native virtual camera output for Windows, I will happily delete half of this article.

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