W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2012

Re: Proposed resolution for open items

From: Randell Jesup <randell-ietf@jesup.org>
Date: Fri, 11 May 2012 15:50:28 -0400
Message-ID: <4FAD6D84.1080001@jesup.org>
To: public-media-capture@w3.org
On 5/11/2012 2:25 AM, Stefan Hakansson LK wrote:
> All,
> for the list of Open Items
> (http://www.w3.org/wiki/Media_Capture#Open_Items), the chairs have the
> following proposal for resolution of these four items:

> "Simple image capture API" [2]: This proposal received mixed feedback.
> Since the chairs could not detect a consensus to add this, they propose
> to postpone this addition to later versions

This is unfortunate, since the only other option is the deprecated 
<input> support (which doesn't get us a lot of things, has issues with 
clicks, etc).  Capturing stills off a video stream without this is not a 
viable alternative.  This will force Instagram-like applications to use 
<input> and not process the data at all locally, or use getUserMedia() 
and only get video capture resolution.  We had earlier talked (months 
ago, I forget when) about the necessity for capturing high-resolution 
stills.  (This might have been within WebRTC before the Task Force started.)

A related issue we haven't discussed in any detail is how to capture 
high resolution stills with preview (i.e. getUserMedia(), and a way to 
say "capture a still now", along with any necessary secondary control 
like flash).

> "Direct assignment of MediaStream to Video": There was a lot of
> discussion. There seem to be a consensus that assignment via
> "createObjectURL" must be supported (since this is an established
> model). Due to this, and to that there does not seem to be consensus for
> direct assignment, the chairs propose that direct assignment should be
> postponed to later versions

This is unfortunate for different reasons; Robert's concern is that 
(IIRC) that streams for which you've called createObjectURL are 
complicated to properly resource track and can lead to unrecoverable 
resource leaks (createObjectURL() and then never assign it anywhere, for 

I far prefer the media.src = stream syntax from a programming point of 
view as well.

The <canvas> assignment seems to have engendered much less discussion 
and is newer; I'd suggest we ask people to indicate if they like the 
proposal or not - we've had one "I don't like it", and one "it seems 
great to me, can you detail how much it helps" (from Paul Neave, who is 
writing sample apps using canvases).

Randell Jesup
Received on Friday, 11 May 2012 19:52:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC