Android hardware VP9 accepts spatial SVC configs but encodes only one layer

What the encoders do

A debugging write-up published on dev.to documents a defect in how Android's hardware VP9 encoders handle Scalable Video Coding. SVC is promoted for mobile as an alternative to simulcast: a single encode produces one bitstream containing several resolutions and frame rates, and the video server drops layers to match each viewer's connection.

According to the report, Android's hardware VP9 encoders do not honor that contract. Configure an encoder for L3T3 — three spatial layers times three temporal layers — and it accepts the mode without complaint. What comes back is one flat stream, usually at the top resolution, and the lower spatial layers never make it into the output.

How the failure surfaces

The symptom is misleading. The server expects three quality tiers and, finding only one, treats the stream as faulty — even though, in the cases described, the network was often healthy. The report's authors observed the same behavior across Samsung and Pixel devices, on both Qualcomm and Tensor silicon, so it is not a single-vendor firmware quirk. Their summary: hardware VP9 on Android handles temporal SVC, while spatial layers are omitted entirely rather than merely degraded.

The most telling production signal is timing. Call quality holds up with a single viewer and collapses once a second one joins — the moment the server starts dropping layers per viewer and discovers there is nothing to drop. The write-up's advice is to check whether the hardware encoder actually emitted more than one spatial layer before blaming connectivity.

No way to ask first

Detection is the deeper problem. MediaCodec reports supported resolutions, bitrates, profiles and temporal schemas, and the report notes that getSupportedLayeringSchemas() on Android 17 still lists only temporal l1tN options. Nothing in the API declares whether spatial SVC genuinely works on a given device. The only reliable check is inspecting the encoded bitstream itself, which is what the authors ended up doing.

The software trade-off

Software VP9, via libvpx, does produce real spatial layers, the report confirms. The price is CPU load and battery drain, which makes it a poor default on phones. Teams building Android video calls are therefore left choosing between correct SVC behavior in software, hardware encoding limited to temporal scalability, or reconsidering simulcast — the very technique SVC was meant to replace on mobile.

Why it matters

SVC's appeal is that one encode can serve every viewer, which matters most on devices with tight CPU and battery budgets. If a platform's hardware encoders silently accept a configuration they cannot deliver, and no API exposes the gap, the failure appears as a confusing mid-call quality collapse rather than a clear setup error. The practical lesson from the dev.to report: treat a successful encoder configuration as unverified, validate layer counts from the bitstream, and never rely on single-viewer testing to prove that SVC works on Android.