Video resolution and simulcast

Configure video resolution, simulcast, and frame rate in RealtimeKit to balance quality against bandwidth. The right settings depend on your grid layout, participant count, and use case.

Video resolution directly affects bandwidth and CPU usage. Sending higher resolution than the display tile requires wastes upload bandwidth and decoding resources on every receiver.

Configure the video resolution in your preset based on the layout each participant type will see.

Each participant occupies a large portion of the screen. Use 1280×720 (720p) as the default. For use cases where visual detail matters — coaching sessions, design reviews, or remote consultations — use 1920×1080 (1080p).

Turn off simulcast for 1:1 calls. With only one receiver, encoding multiple layers adds CPU cost with no benefit.

In a 1:1 call, each participant uploads one stream and downloads one stream. Upload and download bandwidth are equal.

The following table shows per-participant bandwidth and hourly data transfer at 24 FPS for a 1:1 call:

When one or two speakers are the primary focus, push resolution higher. Use 1920×1080 (1080p) as the baseline. Use 3840×2160 (4K) when the host has sufficient upload bandwidth and the content benefits from high fidelity — product showcases, studio interviews, or live art demonstrations.

Turn on simulcast so that viewers on constrained networks automatically receive a lower layer.

The following table shows per-sender upload bandwidth and hourly data transfer at 24 FPS:

Each viewer downloads one stream. The download bitrate matches the sender upload bitrate, or a lower simulcast layer if the viewer's network is constrained.

In a 3×3 grid, each tile is roughly one-third of the screen width. Turn on simulcast and set the sending resolution to 640×480 (480p).

Each participant uploads one stream and downloads eight streams (one from each other participant). The following table shows per-participant bandwidth and hourly data transfer at 24 FPS:

With 16 or more visible tiles, each tile is small. Set the sending resolution to 320×240 (240p) and turn on simulcast.

Each participant uploads one stream and downloads one stream from every other participant. The following table shows per-participant bandwidth for a 4×4 grid (16 participants, 15 incoming streams) at 24 FPS:

At 320×240, each participant needs 2–8 Mbps download. The lower end is practical even on mobile networks. At 1920×1080, the same grid requires 52–210 Mbps download, which exceeds most residential connections.

For layouts where all participants send video but one speaker is pinned at a larger size — town halls, classrooms, or team standups — use different presets for each role.

Set the speaker preset resolution to 1280×720 or 1920×1080 because the speaker tile is large and benefits from higher quality. Set the participant preset resolution to 320×240 because participant tiles are small thumbnails.

The following table shows bandwidth for a town hall with one speaker at 720p and 15 participants at 240p, all at 24 FPS. Every participant sends video:

In a webinar, audience members do not send audio or video unless they are invited on stage. Only the speaker uploads a stream. Use a high-resolution preset for the speaker and a view-only preset for the audience.

The following example shows a webinar with one speaker at 720p and 15 view-only audience members, all at 24 FPS:

Simulcast encodes the sender's video at multiple resolutions simultaneously (for example, 720p, 360p, and 180p). The SFU selects the best layer for each receiver based on available bandwidth and tile size.

Turn on simulcast when:

• The session has three or more participants
• Participants have varying network conditions (mobile and desktop mix)
• The session is a webinar or event with audience on constrained networks

Turn off simulcast for 1:1 calls (one receiver, no benefit from multiple layers) and for audio-only sessions.

Simulcast increases CPU usage on the sender because the device encodes multiple layers. If your use case targets low-powered devices in remote regions with limited bandwidth, consider turning off simulcast and setting a single lower resolution (such as 320×240) for all participants instead. This avoids the extra encoding cost while still keeping bandwidth low. For sessions where participants have a mix of device capabilities and network conditions, simulcast provides the best experience because the SFU delivers the appropriate layer to each receiver.

Frame rate (FPS) directly multiplies bandwidth. Doubling the frame rate roughly doubles the required bitrate at the same resolution. Choose the lowest frame rate that meets your use case.

• Education: Use 15 FPS for lecture screen shares and 24 FPS for the instructor camera. Students on mobile networks benefit from lower bandwidth.
• Healthcare: Use 24 FPS for telemedicine consultations. Higher frame rates provide minimal benefit for conversation-style video.
• Fitness and wellness: Use 30 FPS for live workout classes. Participants need smooth motion to follow physical movements.
• Media and entertainment: Use 60 FPS for live music performances or sports watch parties where motion clarity matters.
• Corporate meetings: Use 24 FPS for all-hands and standups. Talking-head video does not benefit from higher frame rates.
• Customer support: Use 15 FPS for support sessions that involve mostly screen sharing. Lower bandwidth reduces dropped frames on the customer end.

Resolution and frame rate compound. The following table shows per-participant bandwidth for a 4×4 grid (15 incoming streams) at different combinations:

For large-grid use cases like virtual classrooms or all-hands meetings, 320×240 at 15 FPS with simulcast keeps total download bandwidth under 5 Mbps per participant even for high-motion content.

For more information on configuring presets, refer to Presets.