Can one JS document hose a browser's camera capturing ability?

[jan-ivar]

If I understand correctly, if JS doesn't .close() a VideoFrame, and it's in the GPU, can it cause the browser to run out of frames in its GPU buffer pool, and might this stall capture in all sinks in all documents, blowing up mediacapture or WebGPU?

[aboba]

On the receive side,MediaStreamTrackGenerator provides an automatic close() in going from VideoFrame -> track (e.g. for rendering). Section 3.2.3 says:

"When a frame is written to writable, the frame’s close() method is automatically invoked, so that its internal resources are no longer accessible from JavaScript."

However, applications might render using an API other than MediaStreamTrackGenerator such as Canvas, WebGL or WebGPU. Do those alternatives also invoke VideoFrame.close() automatically?

On the send side, a VideoFrame is provided to WebCodecs encode() method, which provides an encodedVideoChunk. However, encode() does not invoke VideoFrame.close() automatically.

Also, there may be use cases (e.g. funny hats, machine learning) where an application could call MediaStreamTrackProcessor to get access to raw media, then process the media. If this processing created intermediate VideoFrame objects that were not passed to MediaStreamTrackGenerator then close() wouldn't be automatically invoked.

[guidou]

To answer the original question, the answer is: not necessarily.
The UA can drop all incoming frames for the stream if it detects that the document using the stream has several open frames and is not closing them.

[guidou]

The spec now explicitly mentions this case and potential mitigations, so closing this issue.