Android ACS Calling SDK: Unable to send video above 640×360 - both RawOutgoingVideoStream and LocalVideoStream

Question

Android ACS Calling SDK: Unable to send video above 640×360 - both RawOutgoingVideoStream and LocalVideoStream

Anto Jose 0

Product

Azure Communication Services Calling SDK for Android - 'com.azure.android:azure-communication-calling:2.16.0'
Features: RawOutgoingVideoStream / VirtualOutgoingVideoStream, and LocalVideoStream

Environment

Device: Google Pixel 5
Camera capture: CameraX (for the raw-frame path)
Call topology: group call (multiple participants / SFU)
Receiver: ACS Web/JS SDK, rendering the incoming video full-screen, with no incoming video constraints applied
RawOutgoingVideoStream VideoStreamFormat configured as:
- Resolution: 1280 × 720
- Pixel format: NV12 (also tested with RGBA)
- Frame rate: 30 fps (configured)
  - Stride1: 1280, Stride2: 1280

Issue

We use the Android ACS Calling SDK to send outgoing video and observe that ACS consistently encodes and transmits at 640×360 using a software H.264 encoder (h264 sw), regardless of the resolution, pixel format, or stream type we provide.

For the raw path, our application generates 1280×720 frames and submits them via sendRawVideoFrame(). The SDK accepts every frame successfully. Our logs confirm the supplied format:

pixelFormat=NV12 1280x720 30fps stride1=1280 stride2=1280

However, the outbound video statistics consistently report:

{
  "bitrateInBps": 172430,
  "codecName": "h264 sw",
  "frameWidth": 640,
  "frameHeight": 360,
  "frameRate": 13.37
}

Questions

Does the Android ACS SDK use a software H.264 encoder (h264 sw) for outgoing video, or should it use the device's hardware encoder (MediaCodec) when available? We observe h264 sw for both RawOutgoingVideoStream and LocalVideoStream on a Pixel 5 (which has a hardware H.264 encoder).
Is the SDK expected to downscale 1280×720 (or 1920×1080) input to 640×360 before encoding?
Are there documented default limits or adaptive policies that cap the transmitted resolution — and specifically, does the group-call topology impose a lower default outgoing resolution than a 1:1 call?
Is there any API or configuration (e.g. OutgoingVideoConstraints) that lets the application request or preserve 1280×720 transmission? If so, what are the supported maximums on Android?

Please let me know if any further details required. This is a critical issue for our product, so any guidance or workaround would be greatly appreciated.

Venkatesan S 10,260 Reputation points Microsoft External Staff Moderator

2026-08-05T21:16:52.2133333+00:00
Hi @Anto Jose ,

Thanks for reaching out in Microsoft Q&A forum,

Does the Android ACS SDK use a software H.264 encoder (h264 sw) for outgoing video, or should it use the device's hardware encoder (MediaCodec) when available? We observe h264 sw for both RawOutgoingVideoStream and LocalVideoStream on a Pixel 5 (which has a hardware H.264 encoder).

There's no documented guarantee that the Android Calling SDK will use the device's hardware MediaCodec H.264 encoder, even when one is available. Encoder selection hardware vs. software is handled internally by the SDK, which means:

There's no public API to force hardware encoding

There's no way to inspect which encoder was chosen at runtime

There's no way to disable the software fallback path

So strictly speaking, observing codecName: "h264 sw" on a Pixel 5 is technically possible under normal SDK behavior Microsoft's documentation doesn't state that hardware encoding is guaranteed on Android.

That said, one detail in your report is worth flagging as a diagnostic lead rather than expected behavior. Your outbound stats show frameRate: 13.37 alongside the resolution drop, and that pairing is meaningful:

A resolution step-down driven purely by bandwidth typically holds frame rate close to target

A frame rate collapse alongside a resolution collapse is more characteristic of the encoder struggling to keep up in real time

This is exactly what you'd expect if the hardware encoder failed to initialize and the engine fell back to a slower software path

To be clear, this isn't documented SDK behavior it's just how this class of adaptation engine typically manifests when the encoder can't sustain real-time performance. And since it repros identically on both RawOutgoingVideoStream and LocalVideoStream, it points to a session- or device-level encoder negotiation issue rather than something specific to your raw NV12 buffers.
MS-DOC:
Access raw audio and video - An Azure Communication Services article | Microsoft Learn

Is the SDK expected to downscale 1280×720 (or 1920×1080) input to 640×360 before encoding?

Yes, downscaling like this fall within documented behavior, not a bug in your capture pipeline. Two pieces of official documentation confirm this directly:

Microsoft states: "The Azure Communication Services Calling SDK automatically adjusts resolutions of video and screen share streams during the call. The resolution can vary depending on the number of participants on a call, the amount of bandwidth available to the client, hardware capabilities of local participant who renders remote video streams and other overall call parameters."

The Video Constraints documentation adds: "The constraint is a max constraint, which means the possible constraint value can be the specified value or smaller. There's no guarantee that the actual value remains the same as user‑specified."

Put together, this means even when you submit 1280×720 frames at 30fps, the SDK is free to downscale to 640×360 or another lower rung of its internal resolution ladder based on real-time conditions resolution and frame rate are targets the SDK adapts toward, not fixed values it locks in once negotiated.

MS-DOC:

Azure Communication Services Calling SDK overview - An Azure Communication Services concept document | Microsoft Learn

Azure Communication Services Video Constraints - An Azure Communication Services concept article | Microsoft Learn

Are there documented default limits or adaptive policies that cap the transmitted resolution — and specifically, does the group-call topology impose a lower default outgoing resolution than a 1:1 call?

On the adaptive policy itself, yes it's documented. Resolution can vary with:

Number of participants on the call

Available bandwidth to the client

Device/hardware capabilities

Other overall call parameters

On the specific group-vs-1:1 question, though, Microsoft doesn't publish a rule that group calls default to a lower resolution than 1:1 calls, and there's no documented statement that 640×360 specifically is an enforced ceiling for group topology. Your observation is consistent with the general adaptive-policy language above, but it isn't something Microsoft states as a fixed, by-design group-call behavior it's more likely a downstream effect of the encoder issue in point 1 than a topology-specific cap.

What is firmly documented is the platform ceiling itself:

Maximum sending resolution on Android: 720p (1280×720)

Maximum receiving/rendering resolution: 1080p, consistent across platforms

MS-DOC:

Voice and video concepts in Azure Communication Services - An Azure Communication Services article | Microsoft Learn

Azure Communication Services Manage Call Quality - An Azure Communication Services concept article | Microsoft Learn

Is there any API or configuration (e.g. OutgoingVideoConstraints) that lets the application request or preserve 1280×720 transmission? If so, what are the supported maximums on Android?

Yes , OutgoingVideoConstraints, which can be set before a call via OutgoingVideoOptions, or dynamically during a call via call.setVideoConstraints():

OutgoingVideoConstraints outgoingVideoConstraints outgoingVideoConstraints OutgoingVideoOptions

On Android, the constraint class supports more than just resolution:

setMaxWidth / setMaxHeight — resolution ceiling

setMaxFrameRate — frame rate ceiling

getMaxBitrateInBps() is also present on the class per the Android SDK reference for 2.16.0, meaning bitrate is constrainable too, not just resolution and frame rate

A few limitations matter here in practice:

These are maximums only the SDK can still choose lower values; there's no way to enforce a minimum or guarantee 720p will be sustained

Constraints set mid-call don't apply to an already-running outgoing stream, you need to stop and restart outgoing video for the change to take effect

The API is currently in preview, without an SLA

There's no API to force hardware encoding or disable adaptive downscaling entirely.

MS-DOC:

Set video constraints in a calling app - An Azure Communication Services article | Microsoft Learn

OutgoingVideoConstraints (Azure Communication Calling version 2.16.0)

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Venkatesan S 10,260 Reputation points Microsoft External Staff Moderator

2026-08-06T19:43:50.8766667+00:00

Hi @Anto Jose ,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Venkatesan S 10,260 Reputation points Microsoft External Staff Moderator

2026-08-08T20:17:21.5933333+00:00

Hi @Anto Jose

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.

Your answer

Venkatesan S 10,260 Reputation points Microsoft External Staff Moderator

2026-08-06T19:43:50.8766667+00:00

Hi @Anto Jose ,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Venkatesan S 10,260 Reputation points Microsoft External Staff Moderator

2026-08-08T20:17:21.5933333+00:00

Hi @Anto Jose

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.