Optimize for Low Bandwidth Networks - Android

When participants join a call from a weak or unstable network, the available bandwidth may not be enough to support the call at its default media settings. VideoSDK provides several controls that you can use to adapt the experience to changing network conditions.

This guide covers recommended approaches for managing the media each participant sends and receives, including choosing the video quality to publish, controlling incoming video, and keeping participants informed as conditions change. These options can help you reduce bandwidth usage and maintain a reliable call experience.

Before the Call

A pre-call screen is where the participant confirms permissions and picks the camera, microphone, and speaker to use. On a connection you expect to be weak, it is also the point at which you choose the media configuration the participant joins with.

Prepare the Participant

• Use the pre-call screen to request permissions and confirm device selection before the meeting is initialized, so the participant does not discover a problem after joining. See Precall Setup.

• Choose the media configuration at this point and pass it to initMeeting() as a custom track. A participant who joins on a constrained connection with a lighter configuration starts the call in a usable state, rather than starting at a high quality that the connection cannot sustain.

• Where you already know the conditions your participants call from, for example a regional deployment or a known field environment, set those defaults for every participant rather than leaving the configuration at its default.

note

There is no connection measurement available before the call on Android. Choose the starting configuration from what you know about your participants, then adapt during the call using the events and controls described in Improve the In-Call Experience.

Configure the Meeting

Use the following settings to control how a participant publishes and receives media. Select the settings based on the participant's network conditions and the requirements of your application.

Configure Published Media

• Pass a configured camera or microphone track to initMeeting() through the customTracks map, using the key video for the camera and mic for the microphone. If a track is not provided, VideoSDK uses its default configuration, which is h720p_w1280p for the camera.
• Create the camera track with createCameraVideoTrack() and the microphone track with createAudioTrack(). Both accept an encoderConfig, while the camera track also accepts bitrateMode, maxLayer, and videoCodec.
• encoderConfig selects the capture resolution. The available presets are h144p_w176p, h240p_w320p, h360p_w640p, h480p_w640p, h480p_w720p, h720p_w960p, h720p_w1280p, and h1080p_w1440p.
• For constrained connections, consider BitrateMode.BANDWIDTH_OPTIMIZED for the camera to reduce bandwidth usage at the selected resolution. BitrateMode.BALANCED is the default, and BitrateMode.HIGH_QUALITY raises the bitrate for connections that can support it. See Optimize Video Tracks for the bitrate used by each configuration and Optimize Audio Track for the available audio configurations.
• You can also configure videoCodec to suit your application's requirements. Codec support varies by device, so see Video Codecs before changing it, and note the interaction with simulcast described in Keep Simulcast Enabled.
• Screen share is configured separately, through the encoderConfig passed to createScreenShareVideoTrack(). The available presets are h360p_30fps, h720p_5fps, h720p_15fps, h1080p_15fps, and h1080p_30fps, with h720p_15fps as the default. On a constrained connection, choose by the content being shared: h720p_5fps keeps text and diagrams readable at a much lower frame rate, while h360p_30fps keeps moving content smooth at a lower resolution.
• To enforce an upper limit on the amount a participant can send, set Maximum Send Bitrate Per Participant for the API key in the VideoSDK Dashboard. The limit applies to every session using that API key and overrides higher bitrate settings configured in your application. See Optimize Audio and Video Usage for details.

Keep Simulcast Enabled

• Enable multiStream on both createCameraVideoTrack() and initMeeting(). The camera then publishes multiple video quality layers, and VideoSDK can deliver an appropriate layer to each participant based on the receiving conditions and requested video quality.
• With multiStream disabled, the camera publishes a single video layer at the configured resolution. All participants then receive that same published layer, even when their network conditions or video layouts differ.
• multiStream is also what the controls in Optimize Incoming Video act on. Adaptive subscriptions, setViewPort(), and setQuality() all choose between published layers, so they have nothing to select from on a single-layer track.
• maxLayer caps how many layers a track publishes, accepts 2 or 3, defaults to 3, and applies only when multiStream is enabled. It never adds layers beyond what the capture resolution allows, so on a lower encoderConfig the two values can produce the same result.
• See Simulcast (Adaptive Bitrate) for what each value publishes.

caution

Simulcast is supported on VP8 only. Requesting AV1, VP9, or H264 together with multiStream falls back to single-layer encoding and reports onError with code 3009 (ERROR_MULTISTREAM_NOT_SUPPORTED). Keep the camera on VP8 when you want every receiver to get a layer suited to its own connection.

Choose the Participant's Media Mode

Use the mode parameter of initMeeting() to control whether a participant publishes and receives media.

Mode	Description
SEND_AND_RECV	Publishes and receives media. This is the default.
RECV_ONLY	Receives media without publishing. Consider this for participants who only need to watch or listen, or when upload bandwidth is limited.
SIGNALLING_ONLY	Does not publish or receive media. Consider this when the participant does not need real-time media.

• Choose a mode that matches the participant's role and network conditions.
• Use changeMode() to switch between modes during the meeting.

Keep the Default Transport Protocol

• initMeeting() accepts a preferredProtocol of UDP_ONLY, UDP_OVER_TCP, or TCP_ONLY. The default is UDP_OVER_TCP, which prefers UDP and falls back to TCP where UDP is blocked. See Initialize Meeting.
• Keep the default on weak networks. It already handles restrictive networks that block UDP, without giving up UDP where it is available.
• TCP_ONLY is worth reaching for only where UDP is known to be unavailable. Real-time media on a lossy connection is generally better served by UDP, because retransmissions and in-order delivery add delay to media that is no longer useful by the time it arrives.

Improve the In-Call Experience

Network and media conditions can change during a meeting. Use VideoSDK events and statistics to keep participants informed when the connection is reconnecting, a stream is interrupted, or media conditions affect their experience.

caution

The in-call controls described below require an active meeting. While the connection is RECONNECTING, calls such as setQuality(), setViewPort(), pauseAllStreams(), enableAdaptiveSubscriptions(), and changeMode() do nothing and report onError with code 3014 (ERROR_MEETING_RECONNECTING). This is worth planning for on a weak network, because a drop is exactly when your application is most likely to attempt an adjustment. Hold the intended change and apply it once onMeetingStateChanged reports CONNECTED.

Keep Participants Informed

Use call and media events to provide clear feedback when conditions change during the meeting. Depending on your application, this can be a snackbar, banner, status indicator, or other in-call message.

Signal	What it tells you	Recommended response
onQualityLimitation	Reports a limitation affecting the local participant's outgoing media. The type can be BANDWIDTH, CONGESTION, or CPU, and the state can be DETECTED or RESOLVED.	When a limitation is detected, consider informing the participant. For bandwidth- or congestion-related limitations, you can also reduce the quality of the published video, for example by replacing the camera track with a lighter one as described in Configure Published Media. A connection sitting near its limit can report DETECTED and RESOLVED in turn, so hold a short delay before showing or clearing the message rather than binding it directly to the event.
onMeetingStateChanged	Indicates a change in the meeting connection state, including RECONNECTING when the connection is interrupted. See Meeting Connection Events.	Show a clear reconnecting message or status indicator so the participant knows the connection is being restored.
onStreamStateChanged	Reports the health of a remote participant's video stream as ACTIVE, FREEZE_DETECTED, FREEZE_RESOLVED, STUCK, or ENDED, along with the peerId and streamId affected.	Show feedback on the participant's tile while their stream is frozen or stuck, so the interruption is explained rather than appearing as a broken tile. Clear the feedback when the stream reports FREEZE_RESOLVED or ACTIVE.
onStreamPaused and onStreamResumed	Report that adaptive subscriptions paused or resumed a stream from a participant, with the kind of stream and the reason. See Scalability for Large Participant.	Show feedback on the tile while its video is paused, so the participant understands the tile is intentionally quiet rather than broken.
getVideoStats() and getAudioStats()	Provide statistics for a participant's media, including values such as bitrate, rtt, jitter, and packetsLost. getShareStats() provides the same for a screen-share stream. See Understanding Call Quality.	Use these statistics when your application needs to identify or display more detailed information about the quality of a stream.

Optimize Incoming Video

Incoming video is usually the largest part of a participant's bandwidth usage, and a participant only benefits from the quality their layout can actually display. We recommend enabling adaptive subscriptions and reporting each tile's size, so every participant receives only the quality their interface requires.

Recommendation	How
Enable adaptive subscriptions	Call enableAdaptiveSubscriptions() after the meeting is joined to let VideoSDK prioritise streams for you. Under bandwidth constraints it pauses muted participants' video first, then the least dominant speakers, and keeps pinned participants at the highest quality. See Scalability for Large Participant.
Report each tile's size	Call setViewPort() with the dimensions of the view rendering the participant, and again when the layout changes. VideoSDK then selects the layer that suits the display area, so a thumbnail does not receive a full-resolution stream. This requires adaptive subscriptions to be enabled.
Control quality yourself	Where you need a manual override, use setQuality() with "low", "med", or "high" to request a specific layer for a participant. This works independently of adaptive subscriptions, so prefer setViewPort() when they are enabled. See Selecting the Video Quality Layer.
Pause streams that are not visible	Use pause() on a stream while a participant is outside the visible area and resume() when they return. This matters most in paginated or scrolling layouts, where tiles leave the screen but keep receiving video. See Grid with Pagination.
Pause a whole media kind	Use pauseAllStreams() with "video", "audio", "share", or "all" to stop receiving one kind entirely, and resumeAllStreams() to restore it. Consider this for an audio-only fallback when a connection cannot sustain video.
Prioritise the participants that matter	Use pin() with "CAM", "SHARE", or "SHARE_AND_CAM" to mark the participants your layout gives prominence to, and unpin() when that changes. Pinned participants are kept at the highest quality while adaptive subscriptions reduce the rest.

Optimize Data Transfers

Call media is not the only traffic using the participant's connection. Image captures and application updates also consume bandwidth, so keeping these transfers efficient can help preserve bandwidth for the call, especially on weak networks.

Capture Images Efficiently

• captureImage() captures a frame from the local participant's camera at its capture resolution. It can only be called on the local participant and requires the camera to be enabled, so the image always comes from the camera itself rather than from a received video layer.
• For use cases such as document capture or identity verification, this means the image quality does not depend on the published video quality. There is no need to raise the published quality in order to obtain a higher-resolution image.
• Pass height and width when a smaller image is sufficient. If these are not provided, the dimensions of the local camera stream are used.

To obtain an image from another participant, request it over pubSub and have that device capture and transfer it:

Recommendation	How
Request the capture from the camera owner	Publish a request on a pubSub topic, then capture the image locally on the device that receives it. See Image Capturer.
Transfer the image through temporary storage	Upload the Base64 image with uploadBase64File(), share the returned URL over pubSub, and retrieve it with fetchBase64File(). This keeps a large payload off the pubSub channel, which other in-call updates share. See File Sharing.

Optimize Message Delivery

Chat, reactions, application state, and other updates can also use bandwidth during a call. Choose the delivery options based on how important the data is and how quickly it becomes outdated.

Use case	Recommendation
Cursor positions, typing indicators, or other frequently changing updates	Set realtimeOverflow to DROP on PubSubSubscribeOptions so the newest updates are delivered and stale ones are discarded rather than queued.
Updates that should survive a brief delay	Set realtimeOverflow to QUEUE with maxQueue, so a subscriber that falls behind can catch up. Anything lost beyond the queue is reported through onMessageDrop.
Persisted messages delivered when a participant joins	Set oldMessageLimit on PubSubSubscribeOptions when the full message history is not required, and newMessageLimit to cap how fast live messages are delivered.
Updates intended for specific participants	Set sendOnly on PubSubPublishOptions so the message is delivered only to the participant IDs that need it, rather than to everyone in the call.
Messages that do not need to reach late joiners	Leave persist disabled on PubSubPublishOptions, which is the default, so the message is not stored and replayed to participants who join later.

See PubSub for the full set of publish and subscribe options.

API Reference

The API references for all the methods and events utilized in this guide are provided below.

• initMeeting()
• createCameraVideoTrack()
• createAudioTrack()
• createScreenShareVideoTrack()
• BitrateMode
• changeMode()
• enableAdaptiveSubscriptions()
• pauseAllStreams()
• resumeAllStreams()
• uploadBase64File()
• fetchBase64File()
• setViewPort()
• quality
• captureImage()
• getVideoStats()
• getAudioStats()
• getShareStats()
• pin()
• unpin()
• pause()
• resume()
• onQualityLimitation
• onMeetingStateChanged
• onStreamStateChanged
• onStreamPaused
• onStreamResumed
• PubSubPublishOptions
• PubSubSubscribeOptions