Re: Media Capture and Streams review from Qualcomm Innovation Center

Hi

Thanks for a detailed review. Please find answers inline.

On 2014-05-18 03:18, Mandyam, Giridhar wrote:
> 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.

The cloning algorithms are specified in the document. Besides the 
property data (e.g. kind and id), a MediaStreamTrack has a corresponding 
source.

We have talked about sending a MediaStream with Web Messaging, but that 
discussion was not resolved.

> 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?

The procedure to generate an id is in the spec [1]. It's basically a 
UUID with some limitations. There are some strange limitations on, e.g., 
length that we could address.

>
> 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?

It means that the user did something that resulted in the stream 
becoming inactive; for example clicked a button. It's a classification 
of the triggering action. We are not consistent throughout the spec when 
it comes to specifying task sources for queued tasks.

> 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.

It's just a simple way to write it. :)

> 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.

See [2]

> 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?

"The source" is the user agent's (browsers) view of the media input 
device. Even though the hardware may be shared with other applications 
on the same machine, they don't share "the source".

> Section 4.3.3.1, readonly attribute.  How does an application make
> use of this?  Would the app leverage this attribute to avoid calling
> applyConstraints() unnecessarily?
>
> Section 4.3.3.1, remote attribute.  Change "track is sourced by an
> RTCPeerConnection" to "track is provided by a non-local source"

I readonly and remote need some more discussion. Do we need both, for 
example?

> Section 4.3.3.2, 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 6 will be removed when something similar is in the media element 
spec [3].

> 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 ..."

Check.

> 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.

This is covered by [4], right?.

> Section 10.2.1, Remove peerIdentity
>

[1] 
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#widl-MediaStream-id

[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25860

[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24684#c20

[4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25855

Received on Tuesday, 3 June 2014 11:01:36 UTC