How do I support video calls in poor network conditions?

To support video calls in poor network conditions, design for adaptation, resilience, and graceful degradation. The key is to keep audio usable first, then scale video quality up or down based on real-time network performance.

1) Prioritize audio over video

In bad network conditions, users usually prefer clear audio with reduced video rather than a frozen high-res stream.

• Keep audio always on if possible
• Lower video bitrate before dropping the call
• Allow video to pause automatically while audio continues
• Consider audio-only fallback when conditions are very poor

2) Use adaptive bitrate and resolution

Continuously adjust stream quality to match available bandwidth.

• Reduce resolution first: 720p → 540p → 360p → 180p
• Reduce frame rate next: 30 fps → 15 fps → 7.5 fps
• Lower bitrate dynamically as congestion increases
• Increase quality gradually after the network stabilizes

If you use WebRTC, this is often handled with congestion control and simulcast/SVC strategies.

3) Use scalable video techniques

These help the sender and receiver adapt without restarting the call.

• Simulcast: send multiple encodings of the same video at different qualities
• SVC (Scalable Video Coding): one stream with layered quality
• Let the receiver subscribe to the best layer it can handle

This is especially useful in multi-party calls.

4) Make the UI resilient

Users should understand what’s happening.

• Show a “poor connection” indicator
• Display current quality mode, if helpful
• Notify users when video is degraded or paused
• Avoid sudden black screens unless necessary
• Keep controls responsive even when media quality drops

5) Buffer and recover intelligently

For live calls, you can’t buffer too much, but you can still smooth instability.

• Use jitter buffers for packet arrival variation
• Adapt playout timing carefully
• Recover from brief packet loss without dropping the stream
• Reconnect quickly if the connection breaks

6) Reduce bandwidth usage

Minimize the amount of data you send.

• Disable HD by default on mobile or cellular
• Avoid background video when not visible
• Stop sending video from inactive participants
• Use bandwidth-efficient codecs like VP8/VP9/AV1 or H.264 depending on device support
• Consider disabling unnecessary data channels or auxiliary streams

7) Handle packet loss and congestion

Poor networks often mean loss, jitter, and latency spikes.

• Use transport protocols that tolerate packet loss well
• Prefer retransmission only when it still makes sense for live media
• Use Forward Error Correction if supported and beneficial
• Detect congestion and back off quickly to avoid making it worse

8) Optimize for mobile and real-world conditions

Mobile networks are often the hardest case.

• Detect cellular vs Wi‑Fi and start conservatively on cellular
• Reduce quality when battery is low or CPU is under load
• Account for switching between networks
• Pause or lower quality when the app is backgrounded

9) Test under adverse conditions

You’ll only know it works if you simulate bad networks.

Test with:

• High latency
• Packet loss
• Jitter
• Bandwidth throttling
• Network switching
• Temporary disconnections

Use traffic shaping tools in your staging environment to reproduce these cases.

10) Define fallback behavior

Have explicit rules for when to degrade.

Example policy:

• Good network: 720p, 30 fps
• Moderate network: 360p, 24 fps
• Poor network: 180p, 15 fps
• Very poor network: audio-only
• Severe failure: reconnect and preserve call state

If you're using WebRTC

A common practical approach is:

• Enable adaptive bitrate
• Use simulcast for group calls
• Monitor stats like RTT, packet loss, jitter, and available outgoing bitrate
• React to getStats() signals and adjust sender parameters
• Use connection state events to trigger UI changes and recovery logic

Good default strategy

If you want the simplest robust approach:

1. Keep audio highest priority
2. Start video at conservative settings
3. Dynamically lower resolution and frame rate
4. Show poor-connection UI
5. Fall back to audio-only when needed
6. Recover quality slowly when conditions improve

If you want, I can also give you:

• a WebRTC-specific implementation plan
• server-side architecture advice
• or a quality adaptation algorithm/pseudocode for poor network conditions.