-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Life-time management of VideoFrame when used with streams #1185
Comments
https://github.com/whatwg/streams/blob/main/streams-for-raw-video-explainer.md#transferring-ownership-streams-explained was a proposal for addressing this. Did anything more come from these conversations? This was highlighted by @tidoust as one of the more painful issues he encountered: https://lists.w3.org/Archives/Public/public-media-wg/2023Mar/0010.html |
I think the plan is pretty clear (as described in the raw video explainer). |
I'm not certain whether we want a new kind of controller or a flag on the existing DefaultController that enables transfers. However, if you could draft something then that would be a big help in seeing what approach is simpler. |
I was thinking of just adding a new flag on default controllers. |
I made some comments over there but in general it looks good. |
VideoFrame objects require to call close so as to clean resources in advance of garbage collection.
This is important as VideoFrame may be big and scarce resources.
Streams currently rely on garbage collection to do the lifetime management, which is an important mismatch with VideoFrame model.
The first consequence is that it is unclear what the API contract is when dealing with streams of VideoFrame.
When reading a ReadableStream, should it be the source or the reader that call close.
Ditto for WritableStream.
It would be good to get a clear understanding of what is desired, document the ideal API contract and, if possible, enforce part or all of the contract in the API and algorithms.
The second issue is that, if a stream has VideoFramed being queued, and the stream gets aborted, we want the VideoFrames to be closed, or at least leave the opportunity for the web application to do that clean-up.
The text was updated successfully, but these errors were encountered: