RE: Scenarios doc updated

More updates pushed to the doc this evening (part 3/3)

>-----Original Message-----
>From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>* Section 4: It is stated that a MediaStream "can be conceptually
>understood as a tube or conduit between a source (the stream's
>generator) and a destination (the sink).". I think that based both on
>the scenarios in this document and earlier discussions a MediaStream can
>have several sinks (just think of the self-view in a conferencing
>scenario).

Tweaked the wording to make this more clear.


>* Section 5.1.2. "Issues": my thinking was that the UA would _not_ be
>able to find out if cameras or microphones are available without
>involving user consent; I thought that would enable finger printing.

I think what you are saying is stated in the "Privacy" section above (5.1.1). The concerns outlined in the Issues section relate to the error callback, scope of the video and audio options as they pertain to multiple cameras/mics, and partial availability of the same.

Perhaps I didn't understand your comment (it happens) :)

I numbered the issues to make future discussion more precise.


>* Again, 5.3.1., I don't understand why you would limit to display one
>version of the captured video. Sure, that is the most natural way, but
>should we not let that be up to the application?

This issue was removed, with a paragraph added recommending that the number
or type of sinks not be limited.


>* 5.5, 5.6: I think a lot of the tools under 5.6.1 are actually usable
>also for pre-processing. And note that the Audio WG now has _three_
>documents in the making, in addition to the "Web Audio API" there is now
>the "Audio Processing API" and the "MediaStream Processing API"! I have
>no clue which will prevail, but for the sake of completeness perhaps all
>should be listed?

Added the Audio Processing API, as well as a note about my view of pre- vs. post-processing scenarios.


>* 5.7, 5.8: Here we have some challenges! Re. 5.7, it may be difficult
>to select the right devices without involving the user. The app may ask
>for a specific video, and the user must select the camera that makes
>most sense.

I see this discussion is on-going on the other thread. No action taken on the scenario doc.


>* 5.9: I think we should allow for several active capturing devices in
>parallel.

I removed the issues from this section and added a paragraph describing what
I believe to be an acceptable loophole for most portable devices.

Received on Friday, 20 January 2012 08:36:07 UTC