← BACK TO HOME
CASE STUDYDEPLOYED

A-Meet

Real-timeROLE — FULL-STACK BUILD

A browser-native video meeting platform built on a mediasoup SFU — simulcast, screen sharing, live captions, and chat, with no installs required.

TYPESCRIPTMEDIASOUP SFUSOCKET.IO
ameet.raja-dev.me
A-Meet — live preview

PROOF

MEASURED, SOURCED
150
COMMITS ON MAIN
GitHub API — repos/Anuraj-dev/A-Meet/commits
105 / 124
PULL REQUESTS MERGED / OPENED
GitHub search API — repo:Anuraj-dev/A-Meet is:pr
54 DAYS
FIRST COMMIT TO LATEST
GitHub API — 30 May to 23 Jul 2026
OPEN REPOSITORY EVIDENCE (4)
69.5%
TYPESCRIPT BY BYTES
GitHub API — /languages, 686 kB of 987 kB
286
FILES TRACKED ON MAIN
GitHub API — git/trees/main?recursive=1
3 x 3
SIMULCAST SPATIAL x TEMPORAL LAYERS
Source — useMediasoup.ts, CAM_VIDEO_ENCODINGS
M0 - M9
MILESTONES SHIPPED
Repository README — milestones table

THE PROBLEM

WHAT NEEDED SOLVING

Almost every browser video-call tutorial stops at a two-person peer connection, and that architecture quietly collapses the moment a third person joins. In a mesh, each browser encodes and uploads a separate copy of its camera to every other participant, so a caller's upload cost climbs with the size of the room and the weakest connection in the call sets the ceiling for everyone. The objective was a meeting that holds up past two people, opens in a tab with nothing to install, and can be self-hosted and read end to end rather than rented as a black box.

THE APPROACH

HOW IT WAS BUILT

A Selective Forwarding Unit — mediasoup — was placed between the participants. Each browser uploads its camera exactly once; the SFU decides which stream, at which quality, reaches each viewer. Cameras are published as three simulcast encodings, so the server can drop a viewer to a smaller layer when their downlink degrades instead of degrading the call for everyone, and audio consumers are pinned to top priority so voice survives a bandwidth collapse that video does not. Socket.IO carries signalling, presence and reconnect; Google OAuth is exchanged for a JWT held in an httpOnly cookie, so no token is ever parked in client storage; MongoDB holds scheduled meetings and invite links. The whole stack — database, log shipper, dashboards — comes up under a single Docker Compose command, with a coturn TURN server included for the networks that refuse to route media directly.

FIELD NOTES

PROBLEMS HIT — AND RESOLVED
  1. 01

    PAST THE TWO-PEER CEILING

    The build reached a working mesh first (milestone M2) and then migrated the entire media path to a mediasoup SFU (M4). Routing every stream through a server the project controls is what turned a demo into something that scales with the room rather than against it — and it moved the hard problems from the browser into code that can be logged, measured and fixed.

  2. 02

    DEGRADE THE PICTURE, NEVER THE VOICE

    Each camera publishes three encodings at roughly 200 kbps, 500 kbps and 1.5 Mbps, every one of them carrying three temporal layers, so the SFU can shed quality for a single struggling viewer without touching anyone else's stream. Temporal layers drop on the next frame instead of waiting for a keyframe, which frees the pipe fast enough that audio stays intact while the picture softens.

  3. 03

    RECONNECTS THAT DO NOT LOSE THE ROOM

    A dropped socket used to strand a participant in a call that no longer knew they existed. Room membership is now re-asserted on every socket reconnect, and first-connection media setup retries on a capped exponential backoff that pauses when the socket is down and restarts with a fresh budget when it returns — so a transient network blip recovers itself instead of requiring a page reload.

  4. 04

    AUDIO CONTROLS WITHOUT THE RACES

    Microphone gain runs through a GainNode that is permanently in the signal chain rather than swapping tracks on the fly. Track replacement is asynchronous and races itself under fast input, which is how volume controls end up stuck or silent; keeping the node in place makes every adjustment synchronous and immediate, and the same audio graph drives the level-reactive speaking indicator.

CAPABILITIES

WHAT IT ACTUALLY DOES
  • mediasoup SFU — one upload per camera, routed per viewer
  • Simulcast: three encodings per camera, shed independently per participant
  • Screen sharing with multi-share, name attribution and a presentation layout
  • Live captions plus a shared transcript every participant can download
  • Google OAuth exchanged for a JWT in an httpOnly cookie — no token in client storage
  • Scheduled meetings with shareable invite links and post-login redirect

ROADMAP

SHIPPED AND OUTSTANDING
  • SHIPPEDM0-M3 — Docker scaffold, Google OAuth to JWT cookie, socket rooms, meeting CRUD
  • SHIPPEDM4 — migration from the WebRTC mesh to a mediasoup SFU
  • SHIPPEDM5-M6 — screen share, reactions, raise hand, chat, landing and lobby UI
  • SHIPPEDM7-M8 — picture-in-picture, simulcast, mic gain, per-participant volume
  • SHIPPEDM9 — connection stability, EC2-aware announced IP, TURN over TLS
  • SHIPPEDDiscord bot v1 — /meet link and /meet create, live in production
  • PLANNEDPersist meeting transcripts — v1 keeps the shared transcript ephemeral, never written to the database