15 August 2026
A frozen video call is almost never a broken camera or a slow laptop — it is packets that never arrived, or arrived too late to be useful. The fix that works most often is the one nobody wants to do first: turn off your own video before you touch anything else.
Video and audio are chopped into packets and fired across the internet in a stream, dozens per second. Each packet has to arrive, and arrive close enough to on-time that the receiving app can still use it. Miss enough of them, or miss the timing window, and the app has two choices: skip ahead and show a blocky mess, or hold the last good frame and freeze until enough packets arrive to catch up. Freezing is the app being conservative, not the app being broken.
Two numbers describe almost every freeze. Packet loss is the percentage of packets that never showed up — anything over roughly 2-3% starts to be visible, and 5% or more usually means regular freezing. Round-trip time (RTT, sometimes shown as ping) is how long a packet takes to get there and an acknowledgment to get back; under 150ms feels live, past 300ms conversation starts to overlap and stutter. Encoders add a third limit: your camera's chip can only compress and send so much data per second, so on a weak connection it drops resolution or frame rate on its own before the network even runs out of room.
Your own video never travels over your own connection to your own screen — the preview you see is a local mirror, drawn straight from your camera before anything gets encoded or sent. If your upload is dropping packets, your camera looks perfectly smooth to you the entire time, because nothing you're looking at ever crossed the network. Everyone else sees the freeze; you see nothing wrong until someone tells you, or until your audio starts cutting out too and you finally notice the delay in what you're hearing back.
This is why 'can you see me okay?' is a real, non-obvious question, not small talk. The connection indicator most apps show — bars, a colored dot, a signal icon — is usually a client-side estimate built from packet loss and RTT measured on your own outbound and inbound streams, updated every few seconds. A green dot means your local math looks fine; it says nothing about what the other four people on the call are actually receiving, because their networks and their video quality are separate problems.
The fixes that work are the boring ones, and they work because they reduce the amount of data competing for the same limited upload. Video is by far the biggest consumer of bandwidth on a call — an audio stream needs roughly 20-40 kbps; video, even at modest quality, needs 10 to 50 times that. That asymmetry is why turning off your camera before your microphone is the single highest-leverage move available to anyone on a struggling connection.
Rejoining the meeting restarts the connection setup but does nothing about the underlying loss or latency if the problem is the network path itself, not the app's session. It sometimes appears to help because conditions changed in the few seconds it took to rejoin — a competing download finished, a WiFi channel cleared up — but that's coincidence, not cause.
Restarting the laptop fixes local software problems: a stuck driver, a runaway process eating CPU that was actually starving the encoder. It has no effect on a saturated upload or a lossy WiFi hop, which is most freezing. Turning captions on or off, changing the meeting layout, or toggling screen share doesn't touch bandwidth in any meaningful way either — those are UI changes, not network changes.
Blaming the app's video quality settings is usually backwards. Most meeting apps already downgrade resolution automatically before things freeze, precisely to avoid freezing — by the time you see it happen, the app has already tried the cheap fixes and run out of room.
If someone's video keeps freezing and audio starts breaking up too — cutting into syllables, arriving late — the connection isn't marginal, it's failing, and no amount of restarting or re-muting will fix a network that can't sustain the call. At that point the honest move is to drop video for everyone on that leg and keep the meeting running on audio, or reschedule if audio alone is also unusable. AVAY's transcript keeps running through all of this regardless of what anyone's camera is doing, since it works off the audio stream — so a call that survives on voice-only still ends with a full, readable record, even if half of it was audio-only.
| Reduces packet loss or RTT? | When it actually helps | |
|---|---|---|
| Turn off your own video | Yes — frees most of the upload | Immediately, on any call |
| Rejoin the meeting | No, unless conditions changed anyway | Rarely, coincidentally |
| Restart the laptop | Only if the bottleneck was local, not network | When CPU or a driver was the real problem |
| Switch WiFi to ethernet | Yes — removes WiFi's own loss and interference | Whenever ethernet is available |
| Close other bandwidth users | Yes — frees shared upload capacity | When something else was competing for it |
The preview you see is drawn straight from your camera, before it's ever encoded or sent anywhere — it never touches the network you're worried about. If your upload is losing packets, that damage happens after your preview is already drawn, so you have no local signal that anything is wrong until someone tells you.
It's a rough, client-side estimate of packet loss and round-trip time on your own connection, recalculated every few seconds. It reflects your network, not the call as a whole — a green indicator on your screen says nothing about whether the person you're talking to is receiving your video cleanly, since their network is a separate problem entirely.
Yes, by a large margin. Audio needs roughly 20-40 kbps to stay clear; video needs anywhere from 10 to 50 times that even at modest quality. Cutting video frees far more bandwidth than cutting audio, which is why turning off the camera is the first move, not the last.
They're sharing the same connection, and once loss or delay gets bad enough it starts affecting every stream on that link, not just video. Audio glitching after video has already been struggling is usually a sign the connection has gotten meaningfully worse, not that a new, separate problem appeared.
Only if the freezing was caused by the laptop running out of CPU to encode video fast enough, which does happen on older machines under load. If the real problem is packet loss or latency on the network, a faster laptop encodes the same data just as fast and sends it into the same lossy connection — nothing changes.
Freezing is packets lost or late on the network, not a broken camera — and because your own video never crosses that network before you see it, you're always the last to know your feed is the one breaking up. Turn off video before audio; it's the one fix that actually frees enough bandwidth to matter.
Meetings that take their own notes, in the browser: avay.ai.