Re: Early Holiday Present: Settings API version 6

On 12/12/2012 08:01 PM, Travis Leithead wrote:
> http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
Many thanks!

Overall I think this looks good. Except for fingerprinting issues (I 
know too little about that to have a good idea of whether this is 
acceptable or not) my personal view is that this looks baked enough for 
starting to include in the Editor's draft.



Some comments:

Section 3
=========
3.2.1: It is said that "stop()" stops the source. But what if other 
tracks depend on the same source? Should it no be that stop detaches 
this track from the source and ends this track; and that a source is 
stopped if no tracks are attached.

Section 4
=========
Section 4.1
-----------
I like this table. However, I think the "remote" part should be moved to 
the webrtc document (but I agree to all definitions).

Section 6
=========
Section 6.1
-----------
First example: I look first on the local part only. In the example the 
two local  sinks are served by two different MS's. What is not clear to 
me is: what happens if the app sets the resolution to 1920*1080 on the 
MS serving sink A followed by setting it to 320*200 on the MS serving B? 
Is it the latest setting that takes effect, or is it the most demanding 
or latest or what? And, what if the track to which the setting was 
applied is ended, or not consumed, what happens?

I think that part was clearer in V5 where you operated on sources rather 
than on tracks.

As a note, another way to do 6.1 would be to have only a single MS that 
serves all the sinks.

Second "Note": I think we should say that "Implementations *are 
encouraged* to make such source-to-sink optimizations" to give naive 
developers power efficient applications with a good user experience.

Section 6.2
-----------
On "Issue 5": I think this will be defined in the webrtc document, but I 
agree to that it is perhaps too cut-and-dry; we have signaling (SDP or 
RTCP) for width and height, so at least that part could apply.

Section 7
=========
7.1, 7.2, 7.9: I think that the mandatory success and error callbacks 
should be added to gUM.

I would like a simple example added, where gUM is used directly to 
create a MS which in turn is directly attached to a video element.

navigator.getUserMedia({audio: true, video: true}, function (stream) {
	document.getElementById("vid").objSource = stream;
	}, function () { log("could not get video") };

<html>
	<video height="400" width="600" id="vid" autoplay muted></video>
</html>

To illustrate that the "old" model still works and have a discussion on 
that the UA should adjust the capturing based on the height/width of the 
element in situations where no constraints are set.

Stefan
>
> This is the original (v5.1) planned revision of the settings v5 proposal, due 2 weeks from our last telecom. It contained enough substantial changes that I bumped the planned version number.
>
> Please read the definitions section (2) which sets out some of the terminology and concepts that will make the rest of the document far easier to understand.
>
> (Brief) Summary of Updates:
> * Martin's proposal for getting the list of device identifiers (sourceIds) is included
> * Bakes in concepts from Martin's synchronous gUM Option 3, notably:
>    - Tracks can take constraints in their constructors
> * "Settings" are now split into capabilities and constraints (there is no more "settings" concept)
> * Further simplified the "source" model from prior proposals
> * Added a concept of "read-only" sources to better allow for either file-backed sources or readonly device-sharing (born from EKR's comments in the telecom).
>
> -Travis
>

Received on Thursday, 13 December 2012 12:32:57 UTC