RE: Image Capture Proposal

Hi Martin,
Thanks.

Actually I was not really sure what the constructor should be.  For instance, see
https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html#videostreamtrack-interface.   Should the constructor a MediaStream, MediaStreamTrack, or a VideoStreamTrack?  

I just kind of punted and tried to define an independent object with a settable stream attribute.  If there is at least one track in the stream corresponding to an imaging-capable device, I assume the UA will take the picture from that track. If there are more than one imaging-capable video tracks in the stream, then the UA will select one of those tracks to take the picture.  But I am open to suggestions on this.

-Giri

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Friday, February 15, 2013 4:07 PM
To: Mandyam, Giridhar
Cc: public-media-capture@w3.org
Subject: Re: Image Capture Proposal

I haven't had a chance to do an in-depth review, but this looks reasonable on face value.

You have neglected to define the constructor though.  I assume that you pass the MediaStream in.

On 15 February 2013 15:20, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> Hello All,
>
> Here is a first stab at separated takePhoto() proposal.  You can also 
> find it at http://gmandyam.github.com/image-capture/.  Some items to note:
>
>
>
> a)      This proposal has dependencies on what we eventually decide on
> constraints/settings.
>
> b)      When settings are requested through the setPhotoSettings() method
> and the UA cannot honor them (for whatever reason), then the 
> appropriate error handler is invoked.  However, I have not defined any 
> kind of error codes or error object for that matter to be passed back.  
> This could change in future revisions.
>
> c)       A onphotosettingschange event handler can be specified.  This
> handler should be invoked any time a settings change occurs (which 
> could happen without the setPhotoSettings method being invoked).
>
> d)      I have not modified the White Balance settings mechanism (leveraging
> an enum) from the original proposal I made last year on camera settings.
> But I am open to suggestions on this, as it seems there can be more 
> flexible ways to specify this (see 
> http://lists.w3.org/Archives/Public/public-media-capture/2013Jan/0005.html).
>
> e)      I have changed ISO setting from an enum to a numeric setting within
> a range.  The UA should determine how to best match the specified ISO 
> setting to the actual ISO values supported by the imaging device.
>
> f)       I still have to verify the code example that I provided, and I
> intend to provide more examples.
>
> g)      Under “Status of this Document” I currently have this as a
> deliverable of the Media Capture TF.  This is not accurate – it should 
> be a deliverable of the WebRTC and DAP WG’s.  I will change this 
> wording to match the wording in the Recording API and the Media 
> Capture spec if the group decides that this document could become a 
> specification from the Media Capture TF.
>
> h)      If we do go forward with a separated takePhoto() spec, then the
> Recording API can be modified appropriately to leave the image capture 
> method out.
>
>
>
> Look forward to any comments/feedback/corrections/concerns.
>
>
>
> -Giri Mandyam, Qualcomm Innovation Center
>
>
>
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Sunday, February 10, 2013 2:43 PM
> To: public-media-capture@w3.org
> Subject: Re: scope of media stream recording and capture 
> specification(s)
>
>
>
> On 02/06/2013 08:14 PM, Glenn Adams wrote:
>
>
>
> On Wed, Feb 6, 2013 at 12:06 PM, Jim Barnett 
> <Jim.Barnett@genesyslab.com>
> wrote:
>
> Glenn,
>
> I agree that we need to clarify the relationship between our specs.  
> You are right that the GetUserMedia document describes how to create a 
> local MediaStream.  However the WebRTC specification
> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) allows you to 
> create a remote MediaStream (one that’s getting its data from a remote 
> peer.) MediaRecorder should work with either type of media stream, so 
> it’s not limited to local streams.
>
>
> getUserMedia defines the general stream model. WebRTC builds upon that 
> definition and extends it.
> The intent of the recording spec is that one should be able to record 
> any stream that builds upon the getUserMedia specification of MediaStream.
>
>
>
>
> In addition to clarifying scope, I would suggest that the following 
> members of the MediaRecorder API be moved to another, less general API 
> or
> specification: image{Height,Width}, takePhoto, onphoto.
>
>
>
>
> I think I heard people say at the interim that they thought 
> takephoto() and friends should be moved to a separate specification.

Received on Saturday, 16 February 2013 00:37:23 UTC