17 August 2026
Of the four things people lump together as "video quality," you only get a real say over resolution (via a cap) and whether your camera is on at all. Framerate and bitrate are set automatically by the encoder's congestion control, and simulcast is invisible plumbing that decides which quality each other person on the call actually receives. When bandwidth gets tight, most apps drop resolution before framerate for a talking head, and the opposite for a screen share full of text.
Resolution is the pixel grid the camera captures and the encoder compresses — 1280x720 ("720p") or 1920x1080 ("1080p") for most webcams. Framerate is how many of those frames get sent per second, usually 15-30 for a face and as low as 5 for a static screen share. Bitrate is the byte budget per second the encoder is allowed to spend compressing all of that — typically 150kbps to about 2.5Mbps for a single video-call stream, higher for screen share with fine text.
Simulcast is the part nobody sets directly: instead of sending one stream, the browser encodes the same camera feed at two or three resolutions at once (say 1080p, 360p, and 180p) and uploads all of them. A server called an SFU (selective forwarding unit) then hands each receiver whichever layer fits their connection, without ever touching your camera settings.
Almost every app gives you two real levers: a resolution cap in settings (720p vs 1080p) and the camera on/off toggle. Some give a third — a screen-share mode that says "optimize for motion" or "optimize for text," which is really just picking which of the remaining two dials to sacrifice. Everything else is arbitration the encoder does dozens of times a second based on measured packet loss and round-trip delay.
In a one-to-one call, your camera often just needs to feed one stream at whatever resolution fits the other person's connection. In a group call through an SFU, your upload cost doesn't multiply per viewer — because of simulcast, you encode and upload two or three fixed layers once, roughly 1.5x the bitrate of your top layer, regardless of whether one person or fifty are watching. What does scale with the number of receivers is the SFU's own outbound bandwidth and each receiver's download, neither of which is your problem to solve.
This is also why one struggling participant doesn't drag the whole meeting down: the SFU can quietly stop forwarding the 1080p layer to that one person and hand them 180p instead, while everyone else on solid connections keeps getting the top layer from the same upload you're already sending. The failure mode people actually hit is CPU, not bandwidth — encoding three simultaneous resolutions, plus background blur, plus screen share, on a five-year-old laptop can pin a core before the network is the bottleneck at all.
WebRTC exposes this as "degradation preference": maintain-framerate, maintain-resolution, or balanced. Apps pick one per stream type, not per call. A talking-head video call usually sacrifices resolution first — a blurrier face is less distracting than a stuttering one. A screen share of a spreadsheet or slide deck usually goes the other way — choppy but sharp beats smooth but unreadable.
Most of what people call "quality settings" in a video app are placebo. A short list of things that measurably help: switch to a wired connection if your wifi backhaul is the bottleneck (upload matters more than download here, and most home plans give you far less of it); cap your camera resolution to 720p on a weak connection so the encoder isn't wasting cycles building a 1080p top layer nobody downstream can use anyway; turn off background blur on a low-power machine, since it competes with the encoder for the same CPU; and close other tabs or apps actively encoding video, since simulcast layer count times resolution is a real CPU line item, not just a network one.
AVAY runs in the browser like any other video call, so it inherits the same resolution/framerate/bitrate arbitration described above — nothing about it changes those trade-offs. What it doesn't need is your video at all: the AI participant transcribes and keeps notes from audio, so turning your camera off to save bandwidth or CPU has zero effect on transcription quality, only on how you look to other people.
| Keeps steady | Drops first | Typically used for | |
|---|---|---|---|
| maintain-framerate | Motion smoothness | Resolution / sharpness | Talking-head video calls |
| maintain-resolution | Pixel sharpness | Frame rate (choppier) | Screen share of text, slides, code |
| balanced | A bit of both | Whichever the encoder judges least noticeable | Apps that don't distinguish stream type |
Only if upload speed, not download, was the bottleneck — and most home plans give far less upload than download. Check your upload number specifically before upgrading; a plan advertised as "200 Mbps" might still only offer 10-20 Mbps up, which is what your encoder actually has to work with.
It's the degradation preference at work. Apps built for screen share usually protect resolution so text stays legible and let framerate drop, so a slow connection makes the share look choppy rather than smeared.
It reduces your own upload and CPU load, which can free up bandwidth for your screen share or a weak wifi link, but it does nothing for anyone else's stream — their quality depends on their own upload and the SFU's routing to their receivers. On AVAY specifically, turning your camera off has no effect on transcription, since notes and decisions are generated from audio.
Simulcast serves a different layer to each receiver based on their measured bandwidth, so that one person is likely getting the 180p layer while others get 1080p from the same upload. It's usually their downlink or their device's CPU, not the meeting itself, that's constrained.
Some apps let you set a resolution floor, but if the bandwidth genuinely isn't there, forcing it doesn't produce a better picture — it produces frozen frames and packet loss where the graceful drop would have gone. Letting the encoder degrade smoothly almost always looks better than fighting it.
You really only choose two things — whether your camera is on and how high its resolution cap goes — and simulcast means eight viewers don't cost you eight times the upload; everything else is the encoder deciding, frame by frame, which quality to give up first.
Meetings that take their own notes, in the browser: avay.ai.