Currently our APIs for reading out payload bytes & Header Extension bytes just pass an ArrayBuffer, but this requires new buffers to be allocated and GCed for every interaction, a cost which adds up at the frequencies & data volumes we're looking at. A bring-your-own-buffer approach would allow apps to maintain their own buffer pools, potentially even directly writing into a WASM memory block, thus avoiding another copy.
Currently our APIs for reading out payload bytes & Header Extension bytes just pass an ArrayBuffer, but this requires new buffers to be allocated and GCed for every interaction, a cost which adds up at the frequencies & data volumes we're looking at. A bring-your-own-buffer approach would allow apps to maintain their own buffer pools, potentially even directly writing into a WASM memory block, thus avoiding another copy.
WebCodecs has taken this approach with all interfaces have a
copyTo(AllowSharedBufferSource destination);
method - eg see https://www.w3.org/TR/webcodecs/#ref-for-dom-encodedaudiochunk-copyto.I suggest we follow this pattern for RTCRtpPacket.payload and RTCRtpHeaderExtension.value.