Re: [whatwg/streams] Editorial changes to transferable streams explainer (#977)

> After all, the workaround for not having this feature is really trival--just make the request for Stream in the Worker/Frame instead (so the transfer is unnecessary). What are the use-cases where the Worker/Frame would be unable to implement that workaround? Why?

Sure, since `fetch` is also available inside a worker, you could just as well have the worker request the data. However, for some use cases, you *have* to touch the main thread to access certain functionality:

* The stream may be coming from an input device only accessible on the main thread. You could use `MediaRecorder` to capture the audio of a user's microphone and/or the video of a user's camera, pipe the captured data through a off-thread `TransformStream` to transcode it into a hypothetical new experimental media format and then upload the resulting stream to a server.
* The stream may need to be displayed on the web page. You could invert the previous example: you download a stream of a video file encoded in an experimental media format, you transcode it to a natively supported format in a worker, and finally you transfer the resulting stream to the main thread to play back the video using `<video>` and `MediaSource`.
* You could have a video editing application as a pure web application, which basically combines the ideas from the two previous examples. You load a local video file or record video from your camera, transcode it in a worker and then store the result to a local file.

(Disclaimer: if I sound _slightly_ biased towards video-related use cases, that's probably because I work for a company in the online video industry. 😛 )

-- 
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/977#issuecomment-454931875