Re: [whatwg/streams] Explainer for proposed stream changes related to VideoFrame processing (PR #1193)

@youennf commented on this pull request.



> +*   `VideoFrame` needs specific management and be closed as quickly as possible, without relying on garbage collection.
+    This is important to not create hangs/stutters in the processing pipeline. By building support for safe patterns
+    directly in streams, this will allow web developers to optimize `VideoFrame` management, and allow user experience
+    to be more consistent accross devices.
+
+## Principles
+
+The envisioned changes to the streams specification could look like the following:
+*   Add a new 'transfer' value that can be passed to `ReadableStream` type, `WritableStream` type and `TransformStream` readableType/writableType.
+    For streams that do not use the 'transfer' type, nothing changes.
+*   Streams of the 'transfer' type can only manipulate that are marked both as Transferable and Serializable.
+*   If an object that is either not Transferable or not Serializable is enqueued or written, the object is ignored as if it was never enqueued/written.
+*   If a Transferable and Serializable object is enqueueud/written in a 'transfer' type `ReadableStreamDefaultController`, `TransformStreamDefaultController`
+    or `WritableStreamDefaultWriter`, create a transferred version of the object using StructuredSerializeWithTransfer/StructuredDeserializeWithTransfer.
+    Proceed with the regular stream algorithm by using the transferred object instead of the object itself.
+*   Introduce a WhatWG streams 'close-able' concept. An object that is 'close-able' defines closing steps.

The idea is to start with a WhatWG stream closable or closable concept, but look at making it a WebIDL concept if there is enough interest. See one of the last item in proposal

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1193#discussion_r769384783