What Actually Happens When Android's Hardware Encoder Hits SVC
Blog post from Stream
Android hardware VP9 encoding can cause livestreams using scalable video coding (SVC) to be incorrectly perceived as network failures when multiple viewers require different resolutions. In testing, a stream worked with one subscriber using a single spatial layer, but when a second viewer prompted the SFU to request three spatial layers, the encoder silently produced only the highest-resolution layer while assigning it the full bitrate, leading the SFU to accurately mark the expected multi-layer stream as poor. Two apparent causes were ruled out: a hardware-encoder teardown cycle caused by resolution changes, which created visible quality oscillation but did not explain the low score, and misleading libWebRTC bitrate statistics that report only the base spatial layer for single-SSRC SVC streams. Tests across Samsung, Pixel, Qualcomm, and Tensor devices indicated that Android hardware VP9 supports temporal layering but not spatial SVC layers, while software VP9 can produce full SVC output at substantial CPU and battery cost. Android APIs do not currently expose spatial-layer support in advance, so validation requires examining the resulting bitstream. As an alternative for one-to-many broadcasts, Stream is developing an opt-in server-side transcoding mode in which the phone sends one efficient stream and the server creates the required quality ladder, shifting the processing cost from the device to the infrastructure.
No tracked trend matches for this post yet.
Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.