W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2012

Re: Synchronous getUserMedia proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 19 Nov 2012 14:13:08 +0100
Message-ID: <50AA3064.7010203@alvestrand.no>
To: public-webrtc@w3.org
Entering the stream early, even though the date is late...

there was an alternate proposal being floated in Lyon.

MediaStreamEventThingy getUserMedia(MediaConstraints constraints, 
optional SuccessCallback, optional ErrorCallback)

interface MediaStreamEventThingy : EventTarget {
    MediaStream theStream;  // in state "muted" until success
    attribute EventHandler onsuccess;
    attribute EventHandler onfailure;

if SuccessCallback is given, this is 100% the same as setting onsuccess 
to function(e) { callback(e.stream) }, and similarly for failure. This 
lets existing code go on working.

This (a result object + onsuccess / onfailure handlers) is a pattern 
that I've observed elsewhere (in IndexedDB, for instance). Not being 
creative is a Good Thing.

Note: People who want to shoot themselves in the foot will do

videoTag.srcObject = GetUserMedia(constraints).theStream

but this is incrementally more difficult than the "simply return a 
stream" option, so it's at least no worse.

On 11/05/2012 11:41 AM, Adam Bergkvist wrote:
> On 2012-11-02 19:32, Martin Thomson wrote:
>> In its simplest form:
>> MediaStream getUserMedia(MediaConstraints constraints);
>> This returns a stream that provides no content (open option: a tainted
>> stream that can only be displayed locally).
>> Consent is indicated with a new onconsent event on the stream; failure
>> reuses the onended event.  A new reason parameter is added to the
>> onended event indicating the reason (this includes all existing onended
>> reason codes, if any, plus all getUserMedia error codes).
>> The major complaint with this is that it leads to an
>> inaccurate/misleading expectation about the usability of the stream.
>> That expectation can lead to the assumption that consent is granted,
>> which would be a bad assumption.
> This approach is not flawless, but to me it seems like the most 
> reasonable one at the moment.
> We already have the concept of a stream that is dispatched to 
> JavaScript but the source is not ready to provide data yet. This 
> currently happens when you receive a stream over a PeerConnection and 
> all the tracks are muted until data arrives over the network. I think 
> gUM() with a return value could be treated similarly, and local data 
> is suspended until the user grants permission.
> In the network case, a media description is used to create the stream 
> and the receiving side and it's pretty capable of describing future 
> stream content. In our local case, the user may only grant one media 
> component. Perhaps ended track state is good enough to solve this.
> I think we'll freak people out if a tainted stream is delivered at 
> once. Even though page authors can't access the content or transport 
> the stream, they can mix the camera view into the page content and 
> that may make people uncomfortable (depending on the page they're 
> visiting).
> /Adam
Received on Monday, 19 November 2012 13:13:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:35 UTC