- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sat, 7 Sep 2013 10:54:48 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-09-07 00:35, Martin Thomson wrote: > On 6 September 2013 15:00, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: >> If getUserMedia returned muted streams which may contain something valuable >> later, then browsers can defer bothering the user until there's a need. >> >> This untangles the UX from the API, and lets browsers manage their users >> without encumbering the web-developer. > > I think that you are describing something very much like what was in > the settings API proposal > > Sadly, https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/SettingsAPI_proposal_v6.html > is 404. > > Here's the basic idea: > > var video = new VideoMediaStreamTrack(videoConstraints); > var audio = new AudioMediaStreamTrack(audioConstraints); > var stream = new MediaStream([video, audio]); > // -> go and use the stream for signaling setup etc... > navigator.getUserMedia(stream, callback, err); // this just > connects the tracks to active sources I like this model. And what Cullen said at the WebRTC call the other day - that existing video conf solutions often start sending video before everything is ready just to get past the slow start - reinforces this. With this model you could do that (even if what you're sending until user consent is silence/blackness) IIUC.
Received on Saturday, 7 September 2013 10:55:12 UTC