Re: Synchronous getUserMedia proposal

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