RE: Comments to requirements

Responses in-line:

-----Original Message-----
From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Thursday, August 23, 2012 8:25 AM
To: public-media-capture@w3.org
Subject: Comments to requirements

Back in July ([1]) Jim added requirements to the scenarios document.

Jim, many thanks for doing that, and apologies for not giving any
feedback until now.

I think this looks generally good. I have some comments to some of the
requirement, and propose that some requirements in the webrtc req
document should perhaps also be added here. See below.

Br,
Stefan

Some comments on the requirements in the current draft
===================================================================

     PERMISSIONS
     3. The UA must request the user's permission before sending or
receiving a media stream to or from another user.
-- I am not sure this is a relevant requirement. The model, as I've
understood it, is that the permission model asks only for permission to
access user media. From there the user has to trust the app; it could
send a media stream to a peer - or it could record to a file and send
wherever.
>> Use case 2.2 mentions explicit authorization from the user before
sending media to a remote site.  If the request for authorization comes
from the app, not the UA, we should make that clear in the use case.
For my part, I'd be pretty annoyed if an app sent media to a remote site
without telling me.  It's still unclear to me how much we trust the app.
We discuss it on the list over and over again, and never reach a
consensus.

LOCAL MEDIA

     2. The UA must be able to provide a visual display of the
properties of the sound captured from from a microphone (volume in this
case).

-- In the webrtc/rtcweb use-case+req document [2] there is an associated
requirement "F15: The browser MUST be able to change the level in audio
streams." and API req A15 saying that the app must be able to control
how the browser changes the level. Is that something we should add?

>> Yes, I think so.

     5. The UA must be able to continue sending and/or capturing media
while the tab is in the background.
-- This applies to receiving and rendering as well (if you're in a
videochat, you'd not like the incoming audio to stop being played if you
switch tab)

>> yes, I think so, though there have been different opinions on the
list.

     6. The UA must be able to extract image frames from video.
     7. The UA must be able to insert image frames into a local video
stream (or capture).

-- For the above two, have we at all discussed how to solve them? The
text in the use case mentions the canvas element (to draw a box around
the blue ball) but how would you go from that to a video stream?

>> Inserting images into a video stream seems like a form of media
processing that's outside our scope.  However, if we set up a clear
enough pipeline model, maybe we can make it clear where such processing
would occur.  

     8. The UA must support the use of the local screen/display as a
video source.

-- Agree, but a recorded video should also be allowed to use (the user
should be able to trick the app by selecting a file - that has been
recorded - as video source in the getUserMedia dialogue)

>> agree

     The UA must allow the user to pause or stop media streams via UXes
(and not just the buttons on the underlying hardware.)
-- There are two UXes: one is the browser chrome, the other is what the
app provides. Both should be possible to use for "pause" (if the app has
a pause button), but the chrome method must override the app

>> Shall I add that as a refinement to the current requirements?  It
makes sense.  

REMOTE MEDIA

     1. The UA must be able to transmit media to one or more remote
sites and to receive media from them.

-- A nit: is "sites" the right word? It gets me to think of things like
origin, rather than a "peer" browser.
>> 'site' may not be the right word.  What is a good generic term that
would cover peer browsers, corporate gateways, audio conferencing
systems, etc.? 
     2. The UA must be able to offer a preview of audio and video media
received from a remote site.

-- What does "preview" mean in this context?

>> Good question.  Wouldn't the app just start playing the media and
allow the user to cancel or modify it if he didn't like  it? 

     5. The UA must be able to send or receive a still image over a
video stream.
-- I can see this coming out of the scenario 2.5, but would not a more
natural way to handle this be to send the actual picture to all
participants for display using http or ws?

>> Also a good question.  Is this really an IETF issue involving the
capabilities of the  PeerConnection?  Or is this another media
processing issue?  


     7. Ability for user simply drag a image over a area of website, so
the image is send to all of the other users
-- Again, something that can easily be accomplished even without
MediaStreams of webrtc - I don't think we should add it

>> Agree. 

Media Capture

     5. the UA must enable the Application to set size contraints and
time limits on media capture.
-- Do we really want the app to be able to define constraints in MBs?

>> In some cases, yes, I would think.  I don't think this capability
adds a lot of complexity.  

     7. The UA must enable the Application to use device properties,
such as battery level, to determine when to terminate media capture.
-- At least battery level seems out of scope for this TF - isn't that
DAP turf?

>> Agree

Requirements in the webrtc req doc [2] that might make sense to add in
this document
=======================================================================

>> Agree to the following, but with some questions indicated below.  
F8/A11: the UA must detect when a remote stream is not received any more
(and inform the application)

F9: Echo handling must be supported by UA

F10: Support synchronous playout of audio and video

F18: Support playout of other audio at the same time as an audio stream
is played
>> So is this just media blending?  

A19: Support for handling general audio different from speech (e.g. 
switch off noise reduction)
>> I don't understand the exact intent here?  Is this another example of
media processing?  

[1]
http://lists.w3.org/Archives/Public/public-media-capture/2012Jul/0000.ht
ml
[2]
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirem
ents/?include_text=1

Received on Thursday, 23 August 2012 18:18:17 UTC