W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2014

Media Capture and Streams review from Qualcomm Innovation Center

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Sun, 18 May 2014 01:18:08 +0000
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A1736C824@NASANEXD02E.na.qualcomm.com>
I have read through the latest Editor's Draft at http://dev.w3.org/2011/webrtc/editor/getusermedia.html.  My compliments to the co-editors and the chairs for all the effort put in.

Rather than clog up bugzilla with a lot of bugs that can be addressed via simple email responses, I am enumerating my comments/questions/concerns in this email.  Note that I may go ahead and file bugs if I feel any issues raised here are not getting addressed.

-Giri Mandyam, Qualcomm Innovation Center

Section 3, Terminology:  "... local file sources are not required to have an identifier".  Is there an assumption that local file sources will be identified directly by the end user (e.g. file picker, like in HTML Media Capture)?  If so, it would be good to clarify in this section.

Section 4, Media Stream API:  "Both MediaStream and MediaStreamTrack objects can be cloned".  I've asked this before and I'll ask again - is this a structured clone or not?  I don't see a reason why a track or stream clone cannot be a structured clone.

Section 4, "When a MediaStream object is being generated from a local file ...".  This paragraph is missing a step, in that the file has to be chosen.  Since the spec doesn't mention any file picker in normative text (only under Best Practice 1), and the file ID is not available to the application, it seems that this capability is not really addressed in the standard.  The SourceTypeEnum doesn't even acknowledge files.  If my interpretation is correct, then I would recommend removing all mention in the normative sections of the text of creating MediaStreams from files and let implementations handle it by any means they choose  - the guidance in Best Practice 1 is sufficient in my opinion.

Section 4.2:  "Initialized stream's id attribute to a newly generated value."  Is this value unique for each origin?  For each webpage?

Section 4.2, "IF the stream's activity status changed due to a user request ...".  How would the user request be obtained?  Directly by the UA through a dialog?

Section 4.2.3, getTrackById,  "... MUST return the first MediaStreamTrack object in this stream's track set whose id is equal to trackId."  The id is unique, so requiring return of the 'first' MediaStreamTrack object is unnecessary.

Section 4.2.3, getAudioTracks, getVideoTracks:  Why did we not simplify to a getTracksByKind(DOMString kind) type method?  I know we have discussed this before in this group, but I could not determine the reasoning when I looked back in the archives.

Section 4.3, "When all tracks using a source have been stopped, the given permission for that source is revoked and the source is stopped."  This guidance assumes that there are no native applications also simultaneously receiving media from the source - correct?

Section, readonly attribute.  How does an application make use of this?  Would the app leverage this attribute to avoid calling applyConstraints() unnecessarily?

Section, remote attribute.  Change "track is sourced by an RTCPeerConnection" to "track is provided by a non-local source"

Section, getNativeSettings().  I don't see the compelling use case for this method.  Unless one can be provided, I recommend removal.

Section 4.3.6, Isolated Media Streams:  I see no use case for this feature outside of WebRTC.  I recommend removal of the peerIdentity constraint in this specification, and  I recommend removal of this whole section.  We can even briefly discuss this during the F2F.

Section 5:  This section should be marked as non-normative.

Section 6.1.1:  Remove Issue 1.  "other types" have not been explored in any detail and shouldn't be considered for this version of the spec.

Section 8:  Under "Fired when ..." for unmute, this even should only be fired after a "mute" event has been fired.  Clarifying language would be useful.

9.2.2, under groupId:  "Two devices has ..." should be "Two devices have ..."

Section 10.1.1, Step 8 ("For each media type T in requestedMediaTypes"):  I don't believe this is the only way to for the UA to traverse constraints.  Steps 1 through 11 can either be marked as non-normative, or language should be added to allow for equivalent UA traversal of the constraint set without following the specific steps outlined here.

Section 10.2.1, Remove peerIdentity

Received on Sunday, 18 May 2014 01:18:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:27 UTC