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

@youennf commented on this pull request.



> +    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' type to `ReadableStream`, `WritableStream` and `TransformStream`.
+    For streams that do not have the 'transfer' type, nothing changes.
+*   Streams of the 'transfer' type can only manipulate Transferable or Serializable objects.
+    If a non Transferable or Serializable object is enqueued or written, the object is ignored as if it was never enqueued/written.
+*   If a Transferable object is enqueueud/written in a 'transfer' type `ReadableStreamDefaultController`, `TransformStreamDefaultController`
+    or `WritableStreamDefaultWriter`, create a copy of the object using StructuredSerializeWithTransfer/StructuredDeserializeWithTransfer.
+    Proceed with the regular stream algorithm by using the copy of the object instead of the object itself.
+*   If a Serializable object is enqueueud/written in a 'transfer' type `ReadableStreamDefaultController`, `TransformStreamDefaultController`
+    or `WritableStreamDefaultWriter`, create a copy of the object using StructuredSerialize/StructuredDeserialize.
+    Proceed with the regular stream algorithm by using the copy of the object instead of the object itself.

This is probably safer but probably unneeded in the case of transferable (& serialisable) since the object would have been transferred then closed. I guess the question remains for serialisable but not transferable objects. Use case only requires Transferable+Serializable.

-- 
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_r761031320