W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2011

Re: First draft available

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 30 Nov 2011 15:22:14 +0100
Message-ID: <4ED63C16.9010505@ericsson.com>
To: Robin Berjon <robin@berjon.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Hi Robin,

thanks for the really quick feedback. Some responses in line.


On 11/30/2011 12:38 PM, Robin Berjon wrote:
> Hi,
> On Nov 30, 2011, at 12:05 , Stefan Håkansson LK wrote:
>> to get started, a first Editor's draft (based on getUserMedia in
>> the WebRTC 1.0 document) has been
>> created:<http://dev.w3.org/2011/webrtc/editor/getusermedia.html>.
>> The initial editors are Dan Burnett and Anant Narayanan.
> Excellent! Thanks for getting this ball rolling. Some quick notes
> follow (in no order whatsoever).
> We will need to sort out the boilerplate so that it matches joint IPR
> coverage. Not something we need to do now but we'll need to handle it
> before publication.
> Why is the title "getusermedia" when the method is getUserMedia?
> Perhaps a simpler, shorter title would work better. I don't want to
> bikeshed and think the editors should make the call, but maybe Media
> Capture API, or Local Media Capture API?
Agree, the title was not at all thought about. We wanted to get the ball 
> getUserMedia() uses the success/error callback approach, which is
> increasingly disliked. I would suggest either returning an object on
> which handlers can be set:
> var um = navigator.getUserMedia(options); um.onsuccess = function
> (stream) { ... }; um.onerror = function (err) { ... }; um.start();
> Or the Node-style compound callback:
> navigator.getUserMedia(options, function (err, stream) {...});
> I personally have a preference for the latter, but that is naturally
> up for discussion.
This is a good discussion to have on this list I think!
> Do we expect LocalMediaStream to remain outside of this spec? I don't
> have an opinion on this, I'm just curious about the thinking behind
> the cut.
Basically there was not that much thinking. LocalStream inherits from 
MediaStream, so we figured that cutting this way was cleaner (or at 
least simpler when cutting / pasting from the webrtc document....)
> One issue that remains fully open is the capture of stills. A typical
> use case would be to acquire the video feed from a camera in order
> for it to serve as a viewfinder in the application, and then be able
> to trigger a still capture from the device. Note that frame-grabbing
> is not at all an option here since you will never get anywhere near
> the quality that the device can produce.
I agree, this must be addressed.
Received on Wednesday, 30 November 2011 14:22:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:08 UTC