Re: getUserMedia WebIDL feedback

Hi,

I did some reading last night, and have a few comments as well:

* 2.1 I think it would make sense to explain the relation between mute 
and enable states, and how that is intended to work

* 2.1 (and at many other places) is there a reason why the text always 
say "finished" while the state is "ended" for MediaStreams? Would make 
more sense to have the same term in both contexts to me

* 2.1 it is said that, when creating a new MediaStream using the 
constructor, the list of tracks can be "either the track lists of 
another stream, subsets of such lists, or compositions of 
MediaStreamTrack objects from different MediaStream objects.". I think 
only the first option is possible with what is in the spec now.

* 2.2.1, for audioTracks and videoTracks, it is said they must return 
"object...that is _fixed length_...". What does "fixed length" mean, and 
is it in conflict with the possibility to extend by doing 
MediaStreamTrackList.add?

* 2.4: Missing ")" after the word "zero".

* 2.4.1, last attribute, last word: "(1)" should be "(0)" (but will I 
guess be irrelevant when moving to strings instead of constants)

* 2.6.3, method "add": I think that there should be a step to "increase 
length by one" somewhere

* 2.6.3, method "remove": I think we need to add text saying that 
"length" is not changed (and why the design is done that way)

* 3.1.1, for getUserMedia: it is said that "user accepts, the 
successCallback is invoked"; but must not also all _mandatory_ 
constraints be fulfilled?

* 3.1.1, for getUserMedia, step 7.6 (the one starting "Final:": It is 
said that the UA selects one track. But looking at the implementations 
available so far, they present the user with a selection of tracks. I 
think this makes more sense, the drop down menu should list all devices 
that fulfill the mandatory constraints (perhaps the order should be 
given by to what extent the fulfill the optional constraints).

Then there is a question if the user should be allowed to pick only one, 
or several (and thereby creating a stream with e.g. several video 
tracks) should be allowed.

* 4: I would really like to see examples using constraints

Stefan



On 06/04/2012 04:01 PM, Dominique Hazael-Massieux wrote:
> Hi,
>
> A few comments on the latest editors draft for getUserMedia [1], in
> particular with regard to its WebIDL usage, and also based on notes I
> took while writing test cases.
>
> I don't think any of these should prevent us from moving forward with a
> FPWD, FWIW.
>
> Also, I'm happy to bring some of the changes myself to the github
> version if that's preferred.
>
> * MediaStream has a onended settable attribute; shouldn't it be
> inheriting from EventTarget so that one could use addEventListener (and
> thus record several listeners for the event)
>
> * likewise for MediaStreamTrack and onmute/onunmute/onended, and
> MediaStreamTrackList with onaddtrack, onremovetrack
>
> * I'm not clear why the "onended" events aren't triggered when
> MediaStream::stop() is invoked; an explaining note would probably be
> useful
>
> * there are strong requirements on the label attribute for MediaStream,
> but nothing in getUserMedia relies on these requirements — they're
> intended for PeerConnection use cases as far as I can tell; maybe a note
> to that effect would be useful (the alternative would be to move the
> requirements to the WebRTC draft, but that seems a bit heavy handed for
> something that simple)
>
> * readyState on MediaStreamTrack uses integer constants, instead of the
> now recommended string ones
>
> * it's a tad confusing that MediaStream has a boolean for ended, when
> MediaStreamTrack has a ternary value with readyState; not sure if it's
> worth harmonizing though
>
> * the URL section should link to http://www.w3.org/TR/url/
>
> * I'm not sure what's the point of having the success callback for
> getUserMedia to be nullable since the only effects is to abort the call
>
> * rather than minting our own error object (NavigatorUserMediaError), it
> is recommended to use instead DOMError; NotSupportedError is already a
> well-defined DOMError type [2]; MANDATORY_UNSATIFIED_ERR isn't, but I'm
> not sure we need a separate code; PERMISSION_DENIED might be replaced
> with SecurityError (but that's probably worth checking with
> www-dom@w3.org)
>
> * I'm not sure we need to report an error set of constraints that cannot
> be satisfied (vs only when none of the possible options can be
> satisfied)
>
> * I think the type for MediaStreamConstraints member should be (boolean
> or MediaTrackConstraints) [rather than DOMString, and instead of
> including the dictionary keyword in the type]; the default values should
> be set to false;
>
> * the type for the 1st member of MediaTrackConstraints also includes a
> buggy "dictionary" keyword; instead of a sequence<>, the second member
> should use an array
>
> * I think the "abort these steps" in the getUserMedia algorithm doesn't
> match what we want when triggering an error (it should instead say "jump
> to the "failures" step)
>
> Dom
>
> 1. http://dev.w3.org/2011/webrtc/editor/getusermedia.html
> 2.
> http://dvcs.w3.org/hg/domcore/raw-file/default/Overview.html#error-types-table
>
>
>

Received on Tuesday, 5 June 2012 11:44:46 UTC