- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Apr 2021 12:13:25 +0000
- To: public-webrtc-logs@w3.org
To summarize the answer to the question if ReadableStream/WritableStream is the right approach: a) _Is streams the right approach?_ I believe it is. It gives us production-ready mechanisms with multiple advantages, such as transferability, a familiar interface and a well-known programming model. It is a natural match for what we want to do, which is exposing media data as stream. b) _Is separating readable and writable the right approach?_ I believe it is. Unlike a transform-only approach, separating readable and writable allows us to support more valid use cases such as: - Custom sinks: For example, you can pair breakout box with WebCodecs and WebTransport and implement a custom communications protocol. [Zoom is reportedly testing this](https://www.infoq.com/news/2020/08/zoom-web-chrome-apis/,). - Custom sources: symmetric with the custom sink case. - Multiple-source track: For example, produce a "weather report" track that combines a webcam track and a video/presentation track. c) _Should we allow processing on the main thread?_. Streams make it convenient to do processing both on the main thread and on workers. The fact that many applications are currently using video element + canvas + canvas capture with much (or all) of the processing on the main thread means that the main thread works well in many production scenarios, so it's not necessarily something we should try to forbid or make excessively difficult. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/4#issuecomment-825615998 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 April 2021 12:13:27 UTC