Re: Updated Media Capture and Streams editor's draft

Replies to some of your questions/comments embedded below.

-- dan

On May 3, 2013, at 1:36 PM, Mandyam, Giridhar wrote:

> Thanks; the current draft looks really good.
> 
> Comments/questions:
> 
> Terminology:
> a) Source:  "Sources do not have constraints ...".  Does this imply anything about whether sources have settings, and whether those settings can be changed by the end user?

Sources can of course change their settings based on user actions directly with the source.  If such a change would cause the setting to be incompatible with the mandatory constraints of tracks tied to the source, those tracks will become overconstrained.

> 
> b) State (Source State):  "A source's state must always conform to the current set of mandatory constraints ...".  Why is this requirement necessary?  If the implementation can comply with a set of mandatory constraints that are not in conformance with the source's state, then this should be acceptable behavior.  For instance, if a source is limited to 10 fps but an implementation can satisfy 30 fps through some form of e.g. motion interpolation - then why should this be prohibited by the spec?

Let's discuss on today's call.

> 
> c) Constraints: " It is possible for two tracks that share a unique source to apply contradictory constraints. Under such contradictions, the implementation will mute both tracks and notify them that they are over-constrained. " This needs to be re-worded.  Contradictory optional constraints should not lead to an over-constrained situation.  

Yes, I will clarify that it is only contradictory *mandatory* constraints that matter here.

> 
> Section 4
> 
> a) Section 4.1:  " Both MediaStream and MediaStreamTrack objects can be cloned. This allows for greater control since the separate instances can be manipulated and consumed individually. "  Can we be more specific and call these structured clones, as defined in http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#safe-passing-of-structured-data?  Any attempt to actually manipulate mandatory constraints on a cloned track would seem to result in an overconstrained situation, so the idea of a track clone being anything other than a structured clone seems not to be possible.  I would appreciate an explanation if I am incorrect.
> 
> b) Section 4.1:  " When a MediaStream object is being generated from a local file ...".  If we are discussing more futuristic features, why not also include generation of a MediaStream from a <video>/<audio> tag as well?
> 
> c) Section 4.2:  I think the MediaStream attribute should be called 'finished' instead of 'ended', if anything so as to distinguish the final state of a MediaStream object from the final state of its constituent tracks.  But this may have already been discussed within the group; if so, I don't want to re-open discussion on this topic because it is trivial.
> 
> d) Section 4.2:  Should the MediaStream TrackID be immutable?  The text is silent on this, but there seems to be a potential issue using with the MediaStream constructor if the track ID's as a result of MediaStream creation.  For instance, if the MediaStreamTrackSequence has to video tracks uniquely identified by ID, then the developer may have an expectation that those ID's are preserved when a MediaStream is created from this track sequence.   I looked through the recent cloning discussion on the mail list but I couldn't find whether this was ever addressed.
> 
> e) Section 4.2.2: Similar question as previous comment for when clone() is invoked.  The stream ID is different for the clone, but are TrackID's preserved in the clone?
> 
> f) Section 4.2: I don't understand who the consumer is for the MediaStream ID.  This ID can be created and be globally unique, but I am not understanding why it needs to be exposed as an attribute on the stream object.  This may have been discussed before in the group - if so, I don't want to unnecessarily re-open a resolved issue.
> 
> g) Section 4.2.2: We could collapse getVideoTracks() and getAudioTracks() into a single method, e.g. getTracks (optional DOMString type), where type can be "video" or "audio".  

 We have gone back and forth on this one as a group.  Personally I hate having everything separated by media type, but the consensus in the group has largely been in favor of this separation.

> 
> h) Section 4.3.1:  For completeness, it would be good to include a mention on memory management (i.e. when can a  stream or track can be GC'ed or deleted, e.g. see https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#lifetime-AudioNode) 
> 
> i) Section 4.3.3.1:  id attribute.  Taken with http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-02, it would seem that the W3C has a different interpretation of MediaStreamTrack ID from the IETF.  Should the msid and MediaStreamTrack ID's be equivalent?
> 
> j) Section 4.3.4:  I had commented separately that it would be good to get rid of the "photo-camera" source type and instead raise an error when takePhoto() is called on a source incapable of taking photos.

Right.  I think this source type should just be removed.  I presume this will be handled by your image capture spec.

> 
> Section 11
> 
> a) I'd remove Example 2.  We have takePhoto() and getFrame() methods defined now, so there is no need to do things this way.  I think an example about applying constraints to a MediaStreamTrack after it has been created might be a more useful example.

The explanatory text (and diagrams) from Travis' original proposal that I still need to add may provide that example.

> 
> Section 12
> 
> a) I thought "zoom" was considered an acceptable track constraint.  It is important for camera preview streams.  Can it be added back in?  I realize that a preview stream can be "zoomed" using CSS transforms (e.g. scale:  ), but this may not be an accurate imitation of the camera zoom operation.

We still have not made any decision regarding what actual constraints will be defined in this spec.  As far as general interest goes, there was vastly more interest in aspectRatio than in zoom, but again, that is a different conversation.

> 
> b) VideoFacingModeEnum was not defined in the doc anywhere (at least I could not find it).  

I'll check.  That was an oversight, if so.

> 
> -----Original Message-----
> From: Dan Burnett [mailto:dburnett@voxeo.com] 
> Sent: Monday, April 29, 2013 10:07 PM
> To: public-media-capture@w3.org
> Subject: Updated Media Capture and Streams editor's draft
> 
> Hi
> 
> A new version of the editor's draft is available.
> 
> Dated version: http://dev.w3.org/2011/webrtc/editor/archives/20130429/getusermedia.html
> Living document: http://dev.w3.org/2011/webrtc/editor/getusermedia.html  (yes, this shows a date of 20130430 -- this is an artifact of publishing after midnight Boston time, so ignore it)
> 
> 
> Changes include:
> 	* Added readonly and remote attributes to MediaStreamTrack
> 	* Removed getConstraint(), setConstraint(), appendConstraint(), and prependConstraint().
> 	* Added source states. Added states() method on tracks. Moved sourceType and sourceId to be states.
> 	* Added source capabilities. Added capabilities() method on tracks.
> 	* Added clarifying text about MediaStreamTrack lifecycle and mediaflow.
> 	* Made MediaStreamTrack cloning explicit.
> 	* Removed takePhoto() and friends from VideoStreamTrack (we have a separate Image Capture Spec).
> 	* Made getUserMedia() error callback mandatory.
> 
> Please review and provide feedback.
> 
> Dan Burnett (for the editors)
> 
> 
>

Received on Tuesday, 7 May 2013 14:08:39 UTC