WebRgbaConverter

Converts video frames to RGBA without the pixels ever entering Kotlin memory.

Why this exists at all, when copyPlanesToByteArray is right there

Because that one is twenty times slower on the web, and the difference is not the conversion, it is the crossing. Kotlin/Wasm has no bulk typed-array bridge, so a ByteArray of pixels is filled one byte at a time through a JS call each: the web probe measured that path at 160 to 240 ms per 1080p frame against a 33.3 ms budget, which is not playback. Doing the same work with the conversion in C and the result handed straight to a JS array measured 8.5 to 9.7 ms.

So this class never returns pixels. It fills a JS array the CALLER owns, which in practice is an ImageData.data a canvas is about to draw. The bytes go from the codec module's heap into that array in one JS set, and Kotlin only ever passes two integers and a handle.

Owning one of these

The scratch buffer is reused across frames and grows only when a bigger frame arrives, because a 4K frame is 24.9 MB and allocating that sixty times a second is the other way to lose the measurement. Own one per renderer, not one per frame, and close it with the renderer.

Not thread-safe, which on the web is not a constraint: there are no threads.