RE: Fifth iteration of Settings API now available

Good stuff.  My apologies if I am repeating comments that have already been made:

Section 1.1:
-------------

a) "Work flow for access to additional device streams" section.  You write "Note that this process has to bind a completely new LocalMediaStream to the video tag a second time (if re-using the same video tag) only because the second LocalMediaStream object was different than the first."

Is there a reason that that this is problematic?  This seems that what is going on is simply changing video.src to a new LocalMediaStream.

b) " Usage of getUserMedia for permission rather than for additional device access" section. "... more information can be made available for discovery of additional devices within the approved "category" or "type" of media, and provide a way to obtain those additional devices without needing to go through the 'permissions' route."

If that is really what is actually enabled in your proposal, I believe this contradicts the second Permissions requirement in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#requirements. 

Section 2:
-----------

a) First paragraph.  " With changes to getUserMedia to support a synchronous API ...".

To which changes are you referring?  I don't see any changes supporting synchronicity in the latest draft:  http://dev.w3.org/2011/webrtc/editor/getusermedia.html#navigatorusermedia

Section 3:
-----------

a) Issue 3

Do you have any scenarios in mind where expando properties are needed for the Video/Audio StreamSources?  I don't see how this would help in achieving the scenarios outlined in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html.

Section 3.1:
-------------

a) Attributes: mirror.  

I think this should be "none" for anything but a front-facing ("user" in the Enum) camera.

b) Methods:  getNumDevices. 

i. Why is this provided as a method instead of a readonly attr?
ii. I don't object to this method being present (in fact I support it), but having it hang off of the VideoStreamSource I/F seems awkward.  It might be better to define this method on gUM itself.

Section 3.1.4 VideoMirrorEnum:
--------------------------------------

When is "vertical" used in camera mirror modes?  It is usually a horizontal flip around the vertical axis.

Section 3.1.7
---------------
a) Attribute: gain

This definition is not consistent with the one used in WebAudio (see https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#attributes-GainNode).  Also, what value should be returned if current setting is not discoverable by UA?

Section 3.2.1
---------------
a) readonly attributes

I've already suggested additional picture settings in http://gmandyam.github.com/media-capture/#picturesettings, and based on the lack of objections at our meeting in TPAC I assumed that there were no issues with going forward with the settings as proposed.  What is the best way to  merge your proposal and mine?

Section 3.2.2
----------------
a) data attribute: " An implementation must return a Blob in a format that is capable of being viewed in an HTML <img> tag"

This seems to be only possible if Blob URL is supported by the UA and you can therefore set img.src.  If Blob URL is not supported then what?
 
Section 3.3
-------------

a) In http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#requirements under Remote Media requirements the following is written:  " These requirements for remote media are outside the scope of the Media Capture task force ...".   

Moreover I don't see why it is necessary to distinguish between a RemoteSource and a locally-generated Source at the object level.  RTCpc will return the remote Media Streams as a remoteStreams object.  That should be sufficient to let the developer know that the associated tracks for those streams are not generated locally, and therefore not to expect non-applicable attributes (e.g. zoom, focusMode) in the source object.  

Section 4.1
-------------
a) General question:  why wouldn't a valid sink also be a file?  This would be appropriate for images.

Section 4.2
-------------
a) MediaSettingsList

Is this extensible through the RTCWeb Media Constraints IANA registry?  If so, clarifying text would help.

b) get()/set() for remote sources

Can you produce a desired call flow when these methods are invoked (see http://dev.w3.org/2011/webrtc/editor/webrtc.html#call-flow-browser-to-browser for an example)?  I am assuming that invoking these methods would result in a message exchange between the local and remote web apps.  If am incorrect in my assumption, then can you explain what is the expected UA behavior when these methods are invoked on a remote source?

Section 4.3.2
---------------
a) " A list of settings that failed or succeeded (depending on the event type)"

I don't see a point in returning a settings object that failed.  It would be more useful to return the current settings, even if it is being returned to the onsettingserror handler. Harald may have said something similar in his comment back to you (if I understood him correctly).

-Giri


-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Friday, November 30, 2012 3:40 PM
To: public-media-capture@w3.org
Subject: Fifth iteration of Settings API now available

I've completed updates to a Settings API proposal v5.

http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v5.html

The highlights:
* Simplified settings model
* Simplified mechanism for discovering other camera/mic devices (before calling getUserMedia)
* Dropped the device list concept
* Simpler inheritance for tracks
* Sources are a property of tracks
* More complete definition of how settings are expected to work
* Concepts introduced for constructable tracks and "new" readyState
* New source objects introduced for tracks belonging to remote media streams

I've already received some feedback that I'll re-post here:

* Some properties for settings may be better suited for the track instead of the source (in v5 all settings are on source objects). These include things like width/height on Video tracks.
* Some properties of the tracks may be better suited for the source object instead (like "facing").
* The "get" API might be more useful if it returned the current constraint (or constraint range) applied to the setting (since the properties return the current value).

-Travis

Received on Thursday, 6 December 2012 02:09:57 UTC