- From: Timothy B. Terriberry <tterriberry@mozilla.com>
- Date: Mon, 11 Feb 2013 14:20:14 -0800
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Martin Thomson wrote: > On 11 February 2013 10:20, Travis Leithead > <travis.leithead@microsoft.com> wrote: >>>> Has the possibility and benefits of creating a media sink outside the DOM >>>> been considered? >> >> Is there a specific motivation or use scenario for such a solution, or is >> this just hypothetical? > > I would have thought this to be obvious. If you wish to perform some > non-trivial processing or analysis of a MediaStreamTrack, the only > rational place to do this is on a Worker. Doing in on the main thread > would have a less than good impact on the usability of the > application. Yes, this was part of the design of the MediaStream Processing API (for exactly these reasons). My understanding is that the Web Audio API does not support workers at all. Its ScriptProcessorNodes also only support power-of-two buffer sizes, which are not suitable for low-latency processing of any data sourced from a communications codec, so... I wouldn't count on using those for any WebRTC use case with acceptable quality. You'll have to stick to the built-in processing nodes.
Received on Monday, 11 February 2013 22:20:46 UTC