Re: [whatwg/streams] Allow web devs to synchronize branches with tee()? (#1157)

> I think we want { synchronized: true } to be the default for a ReadableStream from MediaStreamTrackProcessor.

I would find it quite surprising if the behavior or `readable.tee()` depended on how the stream was constructed. Currently, consumers can call `tee()` pretty freely: you might use a bit more memory (if a slow branch builds up a large buffer), but your `read()`s will still complete just as fast (i.e. backpressure works the same). If *some* streams were to do a "synchronized" `tee()` instead, then a consumer may see its `read()`s getting stuck because the stream was tee'd somewhere else, potentially outside of their own code.

It would also be awkward to implement. We'd have to add an internal flag on the `ReadableStream`, perhaps even turn this into a third type of `ReadableStream` (next to "default readable streams" and "readable byte streams"). I don't think this is a good idea.

> To remove coupling, streams would need to deal with frame dropping themselves, which I think we are hesitant to do.

Indeed. At that point, I'd say that Streams is not the right API for your use case. 😕

Perhaps you should consider building your own API to process/transform a stream of video frames, with support for synchronization and frame dropping? You could still add APIs that *interoperate* with Streams "on the border", e.g. a method that converts the output of a `MediaStreamTrackProcessor` into a `ReadableStream` of `VideoFrame`s. But you wouldn't have a `readable` property acting as your "primary output" to feed into a processing pipeline, you would have a different dedicated API for that.

-- 
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/issues/1157#issuecomment-895162054

Received on Monday, 9 August 2021 11:57:04 UTC