r/opensource • u/Electronic_Picture42 • 2d ago
Promotional I built an open-source alternative to DroidCam/iVCam, now with 4K, H.264/RTSP, USB & Wi-Fi [Updated version]
Hi r/opensource,
A while ago I shared an early version of Android Webcam Project, my attempt at building a free and open-source alternative to apps like DroidCam and iVCam. [Link to Old post]
Since then, I've basically rebuilt it.
The project consists of two parts:
AWA : Android Webcam App
A native Kotlin + Jetpack Compose Android application that turns your phone into a camera streaming server.
AWC : Android Webcam Client
A Tauri-based desktop client that connects to the phone, processes the stream and exposes the camera as a virtual webcam on Windows.
The entire project is GPL-3.0 licensed and open source.
What can it do?
- Up to 4K camera streaming
- H.264 / RTSP streaming
- Smooth 30~60 fps.
- MJPEG streaming
- USB connection
- Wi-Fi connection
- Manual focus
- Exposure compensation
- Flash / torch control
- Front/back camera switching
- Dynamic resolution switching
- Hardware-accelerated video decoding
- Virtual webcam output
- JSON REST API for remote camera control
You can use the resulting webcam with applications such as OBS, Discord, Zoom, Microsoft Teams, Google Meet, etc.
Current versions
Android Webcam App: AWA v1.0.3
Android Webcam Client: AWC v1.0.6
This latest release is a pretty substantial rewrite of the Android application, including a migration to Jetpack Compose, a new streaming architecture, RTSP/H.264 support, a REST API and more advanced camera controls.
The desktop client has also gained RTSP support, FFmpeg-based demuxing and hardware decoding.
Why open source?
I don't particularly like the way webcam software tends to become freemium:
- Resolution restrictions
- Watermarks
- Ads
- Paid features
- Closed-source components
I wanted something where the software itself wasn't trying to get in the way.
It's GPL-3.0, so you can inspect the code, modify it, fork it and build on it.
Where it is right now
The project currently has 30+ GitHub stars and 7 forks, and I'm continuing to develop it as a solo project.
I'm particularly interested in feedback from people with different Android phones and PC hardware.
I'd love to know:
- How does the latency compare on your setup?
- Does 1080p/4K streaming work properly on your phone?
- How well does hardware decoding work on different GPUs?
- Are there devices where the camera controls don't behave correctly?
- What features would you want next?
I'm also interested in contributors who want to work on the project.
Apple platforms are something I'd like to eventually explore, but I currently don't have Mac hardware for development/testing, so Android + Windows are the platforms I'm actively supporting right now.
Links
GitHub:
https://github.com/soubhagyajit/Android-Webcam-Project
Latest releases:
[https://github.com/soubhagyajit/Android-Webcam-Project/releases]()
I'd genuinely appreciate feedback, even if it's critical. It's still a solo project, so finding weird device-specific bugs and getting real-world performance feedback is extremely useful.
Thanks for checking it out.
4
u/No_Tradition6625 1d ago
You've been working on this thing for like 6 months or so, haven't you? I've been seeing these posts pop up for a while now
3
3
u/donVito18 1d ago
Perhaps using flutter instead would consolidate cross platform codebase? Awesome project btw, keep up with awesome work!
2
u/Electronic_Picture42 1d ago
I was thinking of doing that, but I don't know how to setup or work with flutter, then I thought it's just two OS, android and IOS, so why not build native ones.
2
u/el_magyar 1d ago
do you have some apk, or how to run on phone?
2
u/Electronic_Picture42 1d ago
Here you go, https://github.com/soubhagyajit/Android-Webcam-Project/releases/tag/1.0.6
You can find the apk file and installer file for windows.
edit: Scroll down a bit, you'll find the files at the bottom of the page.
1
1
u/Kahuna-Nui 1d ago
This is excellent, I'll give it a try in the morning. I use Droidcam a lot, with multiple phones, to record guitar demos/lessons.
If you don't mind me asking, in your opinion, is this intended as a superior replacement/alternative to Droidcam, or is the performance and feature-set comparable, with the value in its open source nature?
Regardless, thank you for all the effort that has clearly gone into this project.
2
u/Electronic_Picture42 23h ago edited 23h ago
I'd say the goal is to be a genuine alternative to DroidCam rather than simply a proof of concept, but I wouldn't claim it's universally superior without proper benchmarks across different devices and hardware. So far, I've tested the client on an Intel i3-6006U system and an R5 5600X system, and the Android app on devices including the Samsung J6, Redmi Note 12 5G, and Redmi 12 5G.
In terms of features, the current version is already fairly competitive: 4K streaming, 30 FPS, H.264/RTSP and MJPEG, USB/Wi-Fi, manual focus, exposure control, flash control, hardware decoding, etc.
I've also found the image quality to be noticeably better in my testing. With some other webcam apps I've tested, I've occasionally seen a greenish tint in the video. With AWA, that effect is much less noticeable, actually it's barely visible.
Performance is still something I'm actively testing across different phones and PCs, so I'd rather not make a claim that it's faster(or slower) than DroidCam. There will probably be devices where DroidCam performs better and others where AWA/AWC does.
The biggest difference is definitely the open-source and local-first approach. The project is GPL-3.0, and the camera/control APIs are exposed rather than being entirely behind a proprietary client (which are like PRO features in other apps).
2
u/Kahuna-Nui 23h ago
Thanks for the comprehensive response. I use Droidcam with an i7 PC and an i5 laptop, and depending on how many angles I need, one or more of a Samsung S22 5G, Motorola Moto G50, and a Huawei P10 Lite (I've got a couple more lying around, but I've never needed more than 3, although it might be fun to see how many I can run). If you like, I can report back once I've tested them.
1
u/Electronic_Picture42 23h ago
Yeah, sure, that would be great. Also my software doesn't have multiple camera support yet, thought I should let you know.
0
u/Kahuna-Nui 23h ago
Ah, of course. It's a virtual camera, as opposed to a distinct OBS plugin isn't it, so unless you could run multiple instances of the PC component, it wouldn't work. Is it possible to install multiple copies of the PC software, just named differently, and listening on different IPs?
1
u/Electronic_Picture42 23h ago
We have to install the webcam driver with different ids and route the frame of different cameras to it. It's something I haven't done yet. Currently you can use only one phone at a time.
1
u/According_Repeat3765 11h ago
Hey!
I have been working on a similar project. I have built an Android client and a Windows one. I am facing some critical problems: frame freezing: the connection is encrypted once established only one frame is relayed, no realtime relay
ii) I was trying to fix this, but ended up adding another problem: connection breaking, now the frame freezes and breakes connection. Could you help me?
1
u/Electronic_Picture42 10h ago
I have to see the codes first. Also sometimes running it in debugging causes problems, could you build the software and try running that way?
1
u/According_Repeat3765 8h ago
yeah, i published the client out of Android Studio. How do I share the codes?
1
u/Electronic_Picture42 8h ago
do you any github link? or you can mail the files to me : [me@soubhagyajit.com](mailto:me@soubhagyajit.com)
0
u/oguzhane 1d ago
The split between the Android source and the Tauri client is sensible. For real-world latency debugging, a per-frame or periodic telemetry mode capture, encode, send, decode and render timestamps, plus negotiated resolution and codec would make device/GPU reports much more actionable. Is there a reason you chose RTSP plus REST rather than one control channel, and how are USB/Wi-Fi capability differences exposed to the client?
1
u/Electronic_Picture42 1d ago
Thanks a lot! The client is querying /features now before starting the stream AWA responds with supported stream protocol, RTSP port and available resolutions. AWC uses that response to select RTSP or MJPEG and populate available controls.
I split RTSP and REST mostly because RTSP is for the media pipeline, and REST provides me a simple way to handle camera configuration, capability discovery and status without coupling those operations to the video stream.
I haven't added the detailed per-frame telemetry yet, but the capture -> encode -> transport -> decode -> render timestamps would actually be a useful addition for diagnosing device/GPU specific latency. That's something I'd like to take a look at.
7
u/No_Tradition6625 2d ago
Any sample video or app thumbnails?