We’re using @zoom/meetingsdk embedded in a web app. When a participant starts screen sharing we see a ~200 MB jump in heap memory (confirmed via Chrome DevTools heap snapshot — entirely JSArrayBufferData, a single new ArrayBuffer).
This is consistent with the WebRTC decoder allocating a frame buffer pool for the incoming share stream.
What we observe: the pool is never released when screen sharing stops. It persists until the user fully leaves the meeting. On the next screen share start the same pool is reused (no second allocation), which is actually efficient.
But if anything causes a re-allocation (e.g. a different presenter sharing at a different resolution), a second pool is layered on top.
Question: Is this buffer retention intentional? Is there any API on the embedded client to explicitly release/free the screen share decode buffers when sharing stops, short of calling leaveMeeting()?
Tested on: Chrome, @zoom/meetingsdk latest, component view.
