Re: Comments to requirements

On 08/23/2012 08:18 PM, Jim Barnett wrote:
> 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.

Re-reading the use-case, I don't really get the impression that the UA 
asks for permission on sending/receiving, rather the app. But my reading 
may be colored by knowing how the current set of APIs are defined!

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

Yep. My (personal) view is that once you allow the access to the camera, 
you have to trust it. The app could record, it could render in a hidden 
video tag, copy to a canvas and save, etc. etc. RTP-streaming to another 
peer is just one way for the app to leak your privacy. (Of course there 
have been discussions on limiting what the app can do, but not any 
concrete resolution as far as I can remember).

> We discuss it on the list over and over again, and never reach a
> consensus.

Yes.

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

That's right. This probably needs more discussion.

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

I think this should be detailed out.

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

I honestly don't know, I just reacted at 'sites'.

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

Yes, that is my point. Of course the app could start playing in a small 
video window, and switch to a large if the user clicks "OK", but it is 
much more app design than a req on the UA IMO.

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

I think we should remove this Requirement (but let's see what others think).

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

If implementors are OK with this then I'm all for it.

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

Exactly. Maybe it does not really have to go into the requirement doc - 
it is self evident that you could play a file in one audio tag while 
playing a stream in another.

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

Yes. This has been brought up in webrtc context. Usually there are 
things like noise suppression employed in VoIP (and telephony) services 
to enhance the intelligibility for the listener (when the talker is in a 
noisy environment). It has been proposed that it must be possible to 
switch off this functionality in certain cases, and there is a 
requirement saying that.

>
> [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 Friday, 24 August 2012 12:58:00 UTC