- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Jun 2021 14:45:50 +0000
- To: public-webrtc-logs@w3.org
> > All these implementation details are core to achieve behavior and efficiency. So core that it is important to have consensus on them and describe them properly. Web audio and web codecs are examples of spec that describe the model. > > https://webaudio.github.io/web-audio-api/#rendering-loop for Web Audio , and https://w3c.github.io/webcodecs/#dom-audiodecoder-decode for Web Codecs (only the audio decoding side on this link, there are lots of other examples). > > This is the bare minimum to do if this is going to ship anywhere. Can you elaborate on why that is the bare minimum if this is going to ship anywhere? I'm not sure if I agree or disagree with you, but my point is that I don't see the need to hardcode a threading model with specific threads. In practice implementations might not necessarily follow it. In Chrome, for example, there are several processes involved in the capture (do we need a process model as well?) and there are different ways to set up threading in the process running JS to achieve the same results. There might be some performance differences depending on the approach, but they would be correct. For example, we could implement it by saying we have a "media" thread where frames are delivered and explain the interactions between this thread and the worker thread. But in Chrome it would also be feasible with some work to set the worker thread as the thread where frames are delivered to a MediaStreamTrackProcessor. Would a threading model prevent one of these approaches? For a MediaStreamTrackGenerator, does it really matter to which thread the frames are sent once they are written? In many cases it will depend on which sinks are connected to the generator. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/27#issuecomment-852185465 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 June 2021 14:46:02 UTC