Coder Legion - Recent posts tagged webrtc

How to build a browser‑based virtual webcam

Mon, 25 May 2026 12:07:57 +0000

What if we could make our video calls even better?

With softer colors, better resolution, a higher frame rate, and a more flattering angle, our video calls would be much more enjoyable. But the laptop webcam falls short of all these expectations, while the camera in our pocket already offers ten times better quality.

The challenge is how to use that phone camera for video calls without installing additional drivers, pushing video through another cloud server, or building a native app for the phone. Let's explore building a Chrome extension and a mobile PWA.

Make a website see the virtual camera ️

Most video conferencing platforms rely on the same browser API, MediaDevices, to capture video. To inject a virtual camera into a website, two things need to happen: the website must believe there is a new device, and calls for that device should return a live stream from the phone's camera.

The camera must be injected before the website collects a list of devices. Therefore, the content script must be injected before any page scripts run, i.e., at document_start.

It should intercept navigator.mediaDevices and override both getUserMedia and enumerateDevices. The overridden enumerateDevices adds a virtual entry to the device list, so the new camera appears in any selector the page uses. The overridden getUserMedia checks the requested device ID: if it matches the virtual device, the call returns a stream from the phone; otherwise, it falls through to the original function.

As an additional measure, it is possible to dispatch an event about changing the device list. In some cases, if the site takes this event into account, it helps ensure the virtual camera is picked up.

What we have now:

export function monkeyPatchMediaDevices({fakeDeviceInfo, onFakeSelected}: PatchMediaDevices): void {
  const mediaDevices = window.navigator.mediaDevices;
  const enumerateDevicesFn = mediaDevices.enumerateDevices.bind(mediaDevices);
  const getUserMediaFn = mediaDevices.getUserMedia.bind(mediaDevices);

  mediaDevices.enumerateDevices = async () => {
    const devices = await enumerateDevicesFn();
    return [...devices, fakeDeviceInfo];
  };

  mediaDevices.getUserMedia = async (constraints) => {
    if (checkDeviceConstraints(constraints, fakeDeviceInfo)) {
      return onFakeSelected(constraints);
    }

    return await getUserMediaFn(constraints);
  };

  mediaDevices.dispatchEvent(new Event('devicechange'));
}

The end result: On any page where the extension has permission to run, the virtual camera appears as an option in a browser-based video app, without any site-specific integration.

WebRTC without a dedicated server

WebRTC requires signaling – a way for two peers to exchange connection offers, answers, and ICE candidates before they can communicate directly. What if we cannot afford a dedicated server?

An alternative is to use Google Drive's appdata folder as a mailbox. Both the desktop extension and the mobile PWA write and read signaling messages to the same hidden folder, which is invisible to users and accessible only by the extension.

The exchange follows a request-response pattern:

 Desktop                  Drive                   Mobile
   ┃                        ┃                        ┃
   ┃ 1. Write offer         ┃                        ┃
   ┃ └────────────────────> ┃                        ┃
   ┃                        ┃                        ┃
   ┃ 2. QR (fileId+token)   ┃                        ┃
   ┃ └──────────────────────╂───────┐                ┃
   ┃                        ┃       │                ┃
   ┃ 3. Poll for answer     ┃       │                ┃
   ┃ ├────────────────────> ┃       │                ┃
   ┃ ┊                      ┃       │                ┃
   ┃ ┊                      ┃       │                ┃ 4. Scan QR
   ┃ ┊                      ┃       └──────────────> ┃
   ┃ ┊                      ┃                        ┃
   ┃ ┊                      ┃                        ┃ 5. Read offer
   ┃ ┊                      ┃ ─────────────────────> ┃
   ┃ ┊                      ┃                        ┃
   ┃ ┊                      ┃                        ┃ 6. Write answer
   ┃ ┊                      ┃ <──────────────────────╂─┘
   ┃ ˅                      ┃                        ┃
   ┃ 7. Read answer         ┃                        ┃
   ┃ <───────────────────── ┃                        ┃
   ┃                        ┃                        ┃
   ┃ 8. Delete all files    ┃                        ┃
   ┃ └────────────────────> ┃                        ┃
   ┃                        ┃                        ┃

To avoid a separate authorization step on the mobile side and ensure that access to the file will be preserved, a Google OAuth token can be embedded directly into the QR code. This means that the QR code contains everything needed to authenticate with Drive, so scanning the QR code is the only action required to establish a connection. A new QR scan is needed for each new connection, but after the WebRTC handshake is complete, the connection can continue without interruption for any duration.

/**
 * Offerer uploads its description and calls back the business part 
 */
public async sendOffer(description: RTCSessionDescriptionInit): Promise<void> {
  const fileCreationResponse = await driveGapi.files.create({
    media: new Blob([JSON.stringify(description)], {type: 'application/json'}),
    name: `${this.options.sessionId}-offer.json`,
    mimeType: 'application/json',
    parents: ['appDataFolder'],
  });

  this.options.onDescriptionCreated(fileCreationResponse.id);
}

/**
 * Answerer downloads the offer and returns it to the business part 
 */
public async checkOffer(): Promise<RTCSessionDescriptionInit> {
  const offerFileBlob = await driveGapi.files.download(this.options.driveId);
  const offerFileJson = await offerFileBlob.text();
  return JSON.parse(offerFileJson) as RTCSessionDescriptionInit;
}

/**
 * Answerer uploads its description 
 */
public async sendAnswer(description: RTCSessionDescriptionInit): Promise<void> {
  const offerFileMeta = await driveGapi.files.get(this.options.driveId);
  const fileCreationResponse = await driveGapi.files.create({
    media: new Blob([JSON.stringify(description)], {type: 'application/json'}),
    name: offerFileMeta.name.replace('offer', 'answer'),
    mimeType: 'application/json',
    parents: ['appDataFolder'],
  });
}

/**
 * Offerer downloads the answer and returns it to the business part 
 */
public async checkAnswer(): Promise<RTCSessionDescriptionInit> {
  const listFilesResponse = await driveGapi.files.list({
    pageSize: 2,
    query: `name contains '${this.options.sessionId}'`,
    spaces: 'appDataFolder',
  });

  const listFiles = listFilesResponse?.files ?? [];
  const answerFileMeta = listFiles.find((file) => file.name.endsWith('-answer.json'));

  if (answerFileMeta) {
    const answerFileBlob = await driveGapi.files.download(answerFileMeta.id);
    const answerFileJson = await answerFileBlob.text();
    const answerDescription = JSON.parse(answerFileJson) as RTCSessionDescriptionInit;

    for (const file of listFiles) {
      await driveGapi.files.delete(file.id);
    }

    return answerDescription;
  }

  return null;
}

Stick it together

To avoid making the user scan a QR code for every call, we can keep a long-lived WebRTC connection alive and reuse it. The ideal place for this connection would be the service worker. Since WebRTC cannot be used there, it's necessary to set up offscreen.

let offscreenSettingUp: Promise<void>;
export async function setupOffscreenDocument(filename = 'offscreen.html'): Promise<void> {
  const offscreenUrl = chrome.runtime.getURL(filename);
  if (await hasOffscreenDocument(offscreenUrl)) {
    return Promise.resolve();
  }

  await (offscreenSettingUp ||= chrome.offscreen.createDocument({
    reasons: ['WEB_RTC'],
    url: offscreenUrl,
    justification: 'WebRTC stuff',
  }));

  offscreenSettingUp = null;
}

However, while there is no way to stream video from offscreen to content script, the only solution is to connect content script to mobile directly. The offscreen document assists with the offer/answer exchange but stays out of the media path.

The architecture that makes it work:

 ┌────────────┐     ┌────────────────┐     ┌────────────────────┐
 │ Side Panel ├───> │ Service Worker │ <───┤ Offscreen Document │
 │  (React)   │ <───┤  (dispatcher)  ├───> │   (WebRTC host)    │
 └────────────┘     └───────┬────────┘     └───────┬────────────┘
                            │ ▲                    │ ▲
                            │ │                    │ │
                            │ │                    │ │
                            ▼ │                    ▼ │
                    ┌─────────┴──────┐     ┌─────────┴──────┐
                    │ Content Script │ <───┤     Mobile     │
                    │ (monkey-patch) │     │    (camera)    │
                    └────────────────┘     └────────────────┘

Side Panel: The UI. A React component that displays the Google Sign-in, the QR code, and device status. All inputs go to the service worker.

Service Worker: A lightweight message dispatcher. This component never touches video. It creates an offscreen document, stores user settings, and proxies messages between the side panel, the offscreen document, and the content script(s).

Offscreen Document: The hidden WebRTC manager. It owns the long-term RTCPeerConnection and uses it to establish new ephemeral connections.

Content Script: Injected into each page. Its only job is to inject the virtual camera with the phone stream, using the monkey patch described above. The script receives the stream from the mobile device and exposes it to the page.

// Configuring peer for receiving video
peer.addTransceiver('video', {direction: 'recvonly'});
peer.addEventListener('track', ({transceiver}) => {
  const track = transceiver.receiver.track;
  track.addEventListener('mute', () => {
    this.options.onStream(null);
  });
  track.addEventListener('unmute', () => {
    this.options.onStream(new MediaStream([track]));
  });
});

// Setting up the stream in the video element
public setStream(targetStream?: MediaStream): void {
  if (targetStream) {
    const videoElement = window.document.createElement('video');
    videoElement.srcObject = targetStream;

    videoElement
      .play()
      .then(() => (this.targetVideo = videoElement));

    return;
  }

  this.disposeTargetStream();
}

// Drawing the video element or a stub animation
private loop(streamOptions: FakeMediaStreamOptions): void {
  window.requestAnimationFrame((time) => {
    if (this.targetVideo) {
      this.canvas.drawVideo(this.targetVideo);
    } else {
      this.canvas.drawStub(time);
    }

    this.loop(streamOptions);
  });
}

What this architecture enables

The solutions chosen in each problem section produced capabilities that weren't designed independently. Instead, they emerged from the overall architecture.

Minimal permissions. The OAuth token stored in the QR code only has two scopes: read and write access to the app's own hidden Drive folder. It doesn't have permission to see files outside that folder or access email, contacts, or other user data.

WebRTC provides built-in security guarantees. Media streams are end-to-end encrypted regardless of the signaling method. The video stays inside the user's WiFi network or, in a fully wired setup, is transferred via USB tethering, which provides a stable wired connection that bypasses Wi-Fi entirely.

Flexibility beyond the webcam. The peer-to-peer nature of the connection allows for any type of data to be transmitted through the same channel. This includes images, screen captures, and even completely different video sources, which can replace the camera feed without affecting the signaling or transport. The architecture views video as just another type of payload among many.

Cross-platform compatibility. The desktop side is a Chrome extension, meaning it works on all operating systems that support a Chromium-based browser, such as Windows, macOS, Linux, and ChromeOS. The mobile side is a PWA, which doesn't require installation from an app store, and works on both Android and iOS. The only exceptions are platform-specific WebRTC behaviors (for example, how iOS Safari handles background streaming differently), but the core connection model remains consistent across all platforms.

The concrete result of this path is Extroid, a Chrome extension that turns your phone into a wireless webcam for any browser-based video call. Extroid is designed for browser-based video calls. See the compatibility guide for supported browsers, meeting apps, and unsupported desktop apps. It works without the need for cloud servers or drivers, and there's no need for a native app on your phone. I'd love to hear your feedback!

We power screen recording inside SaaS products.

Sun, 08 Feb 2026 19:01:13 +0000

https://eyedolise.github.io/chromescreenrecord

Building reliable screen recording into a product looks simple—until you actually do it. Browser limitations, performance tradeoffs, codec issues, resolution caps, and edge cases across devices quickly turn it into a time sink that steals focus from your core roadmap. SCR4K exists so SaaS teams don’t have to fight those battles. We provide a production-ready recording engine that’s already been tested in the real world, so teams can ship faster without compromising quality or stability.

Our recording engine is battle-tested by over 2,300+ users through our flagship Chrome extension, with no watermarks and consistent 4K output—plus an upgrade path beyond Chrome’s native limits up to 8K via our SaaS pipeline. The same engine can be embedded directly into platforms built with React, Angular, or custom stacks, giving teams full control over the user experience while avoiding the cost and risk of building recording infrastructure from scratch.

Instead of selling a generic tool, we license a proven system: source code, integration support, and a commercial-ready recording core designed to scale with your product. Teams use SCR4K to power onboarding, bug reporting, customer support, demos, and internal workflows—without reinventing the wheel. Try the engine yourself, or integrate it directly into your platform. Either way, you’re starting with something that already works.

SaaS #B2BSaaS #SaaSBuilders #StartupEngineering #ProductEngineering #DevTools #SoftwareArchitecture #WebDevelopment #WebRTC #TechFounders

If you want to test the recording engine yourself, you can try the SCR4K Chrome extension here

WebRTC - How does it work ?

Sun, 20 Apr 2025 10:11:19 +0000

What is WebRTC ?

WebRTC stands for Web Real Time Communication -> It allows audio, video and streaming communication to work inside
webpages by allowing direct peer-to-peer communication, eliminating the need to install plugins or download native apps.

Is supported by Apple, Google, Microsoft, Mozilla and Opera, and is an standard way to implement peer-to-peer
communication.

High level flow of WebRTC

A wants to connect to B
A finds out all possible ways that the public can connect to it
B finds out all possible ways that the public can connect to it
A and B signal the session information (supported codecs, mode of communication) via other means (long polling, short polling, websockets)
A connects to B via the most optimal path
A & B can now exchange their supported media

Components at works

WebRTC is fairly complicated and it requires lot of components to work in harmony to be able to establish a P2P
connection. We should know about following components before we go ahead and create a WebRTC app.

NAT, types of NAT
STUN / TURN servers
Signaling, Session Description Protocol (SDP)
ICE, trickle ICE
JS API -> RTCPeerConnection, RTCDataChannel, createOffer(), createAnswer(), setLocalDescription(), setRemoteDescription(), ...so on.

What is NAT ?

NAT stands for Network Address Translation, any device that is connected to the internet, is connected via a router,
so there are 2 networks that are at play here, one is the public network that is the internet and the other one is the
private network which is basically your LAN, so each device connected to a router that is connected to the internet, has
a public IP and a private IP.

You can check your public IP by visiting whatismyipaddress.com
and if you want to check your private IP open up a terminal (windows / Linux) and run ipconfig(windows) or ifconfig (Linux)
and you will get your local IP address.

So, if you want to connect your device (for ex. private IP: 10.0.0.2:8992) to a server / different device (public IP: 4.4.4.4:80) on internet
you would want a public IP address to connect to it, since router will not allow anyone to access the private network,
this is to avoid unsolicited connections - its a basic firewall.

Who assigns the public IP to your device ? Who make sure that you get back the response from the internet to your device ?

The Router. Router acts like a middleman between your device and the public network / internet.

Here is how it works:

A(private IP:10.0.0.2:8992) wants to connect to B (public IP: 4.4.4.4:80)

A creates a request packet like this

Port	Public IP	Request	Destination IP	Destination port
8992	10.0.0.2	GET/	4.4.4.4	80

A forwards the packet to the router -> Router has to decide whether this is a packet on same network or external network ?

Router checks this by a process called subnet matching,

If 2 devices are from same subnet (xxx.xxx.xxx.y) then there is no need to create a NAT table entry, but if not, a entry in NAT table will be created.

This decision is made by router with following logic

10.0.0.1 && 255.255.255.0 -> 10.0.0.0 (lets say this is the gateway and the subnet is 10.0.0.0)

if the IP belongs to same network we should get same subnet for example 10.0.0.0 , else we would get other subnet and
that means that we are trying to connect to an IP outside the private network.

Types of NAT

One-to-one NAT
Address Restricted NAT
Port Restricted NAT
Symmetric NAT -> WebRTC does not like this one -> neither does any real time gaming app

One to One NAT (Full Cone NAT)

Int port	Int IP	External IP	External port	Dest IP	Dest port
8992	10.0.0.2	5.5.5.5	3333	4.4.4.4	80

Outbound: You send a packet to any server.
Inbound: Any external IP & port can send to your mapped public IP / port, once it's open.

✅ Most permissive
Good for P2P, pretty bad for security

Address Restricted NAT

Int port	Int IP	External IP	External port	Dest IP	Dest port
8992	10.0.0.2	5.5.5.5	3333	4.4.4.4	80

Outbound: You send to an external IP.
Inbound: Only that same IP can respond to your public IP/port - any port from that IP is allowed.

✅ Moderate restriction
Safer than full cone

Port restricted NAT

Int port	Int IP	External IP	External port	Dest IP	Dest port
8992	10.0.0.2	5.5.5.5	3333	4.4.4.4	80

Outbound: You send to an external IP & port.
Inbound: Only that exact IP & port can respond.

✅ More restrictive
Tighter control on incoming traffic

Symmetric NAT

Int port	Int IP	External IP	External port	Dest IP	Dest port
8992	10.0.0.2	5.5.5.5	3333	4.4.4.4	80

Outbound: Every outbound (IP: port) gets a unique mapping.
Inbound: Only the exact IP & port you contacted via the specific mapping can respond.

Most restrictive
❌ Hardest for P2P

STUN (Session Traversal utilities for NAT)

STUN server reflects back the public IP address:port combo back to the peer.
STUN has simply one role, get a request from a peer and reflect back its public ip: port
Works well with full cone, address/ port restricted NAT types
Does not work well with Symmetric NAT -> Since every outbound request gets a new mapping in NAT table,
the public IP:port pair, returned by the STUN server could not be used reliably to create a P2P connection.
Around 80 - 85% of devices are behind NATs where STUN works just fine, only few devices (corporate networks, some mobile carriers, hotel / public wifi) are using symmetric NAT
for that we need to make sure we use TURN servers

A simple way to remember this

You ask to a STUN server: Who am I ? (what is my public IP:port ?)
STUN server: This is who you are (public IP: port)

STUN servers are inexpensive and relatively cheap to maintain and you will find a lot of public STUN servers as well
that you could use in your application, implementing a STUN server from scratch too, would not be too complex either.

TURN (Traversal using Relays around NAT)

As we discussed above, in about 10 - 15% cases its possible that the peers use symmetric NAT, that makes it impossible
to create a P2P connection with STUN servers
TURN comes into picture in such cases, TURN server act as a relay server between 2 peers, esentially
- A sends data to a TURN server,
- TURN server sends that data to peer B
- Peer B sends data to TURN server
- TURN server forwards that to peer A
Now the connection is no longer a truly peer-to-peer anymore, latency is higher now, and as you can expect, bandwidth
costs for the TURN servers are higher since they are handling a lot of data.
Typically a WebRTC client will try to connect peers via the STUN method, and if that fails it will fallback to TURN
servers

ICE (Interactive connectivity establishment) candidates

So we have a bunch of STUNs and TURN servers setup now
We want to find what works i.e. is STUN enough or do I need to fallback on TURN ?
This process of determining best possible way to connect to peers is ICE gathering,
Browser tries out multiple connections until it finds a working one, and once that is done, it creates a list of
servers through which the peers can communicate
Once the discovery is complete, we will have ICE candidates that need to be shared via signaling with other peer.

SDP (Session Description protocol)

Session Description Protocol (SDP) is a plain string that describes peers to one another,
What kind of media options, security options are supported by both peers, what kind of connection is being requested
by another peer.
One of the important parts of WebRTC, since this will be exchanged via signaling among peers to even start the process
of ICE gathering,
Goal is to generate a SDP and send it to the other party, how its done depends on your method of signaling.

Signaling

Signaling typically means sending the required information via some channel to both peers (exchanging information)
Now this can be done via almost anything (WhatsApp, QR code, Web sockets, HTTP), web sockets are a popular choice
What do we typically signal ? SDP, ICE candidates -> these need to be exchanged before a connection can be successfully
established between two peers.

Putting everything together... So close to connecting the peers now!

Finally we understand how all the components play in the WebRTC game, now its time to connect

A wants to connect to B
A creates an "offer", it puts all the information about sessions, data channel in the SDP
A signals the SDP to B
At the same time, ICE gathering process starts for A, onicecandidate event handler is called once an ICE candidate is
discovered, this needs to be signaled to B separately
B creates the answer after setting A's offer
B starts ICE gathering process, signals ICE candidates to A
A accepts B's answer
Connection is created.