Re: [rtcweb] Mute implementations (Re: More Comments ondraft-ietf-rtcweb-use-cases-and-requirements-07)

["Jim Barnett" <[e-mail]>]

I still think that there is a significant difference between
files/images and live sources.  A live source provides a lot of
information about my environment - what's going on, whether I have
shaved, etc.  The file or image source that we use for hold is designed
to provide _no_ information about my environment.  In a user's mind,
showing "please wait" or a  images of a waterfall is very different from
showing anything _live_ from his environment, and we may want to reflect
that difference in the requirements.  For example, does the user have to
give explicit permission to show the "Please wait" source when the call
is put on hold, or is that configured as a default in the browser?  (The
latter, I'd  think, which makes it different from the front and rear
cameras.)

 

-          Jim

P.S. I agree that the system can switch from front to rear cameras once
it has permission for both, though it should make it clear that it is
doing so.   

 

From: Harald Alvestrand [mailto:[e-mail]] 
Sent: Sunday, June 17, 2012 4:01 AM
To: Jim Barnett
Cc: [e-mail]
Subject: Re: [rtcweb] Mute implementations (Re: More Comments
ondraft-ietf-rtcweb-use-cases-and-requirements-07)

 

On 06/16/2012 11:58 PM, Jim Barnett wrote: 

It's capturing the requirement accurately that I'm concerned with.  I
think "To be able to change the source of a video stream after its
creation" is too broad, in the sense that someone might interpret it to
mean that the system could shift from the front to the rear camera
without asking permission.

People certainly want to shift from the front to the rear camera, and
people want to have the ability to get all that asking-for-permissions
stuff out of the way before that.

I recommend the Media Task Force's "additional scenarios" for more
usages of "local media".
Jjim, I know you know where this is, but for others:
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.ht
ml




  For mute and hold, we want something like
"switch to a dummy source and back".  The source that we switch to in
cases like this is not a 'first-class' video source, but rather a
place-holder.  That's very different from switching to another live
source.

ObLangDisagreement: Files, images and the output of video processors are
very real sources, and should not be "second class".

Switching between live streams (that we have permission to access) is
going to be required, but I think this belongs on the Media TF mailing
list.




 
 
- Jim
 
-----Original Message-----
From: Harald Alvestrand [mailto:[e-mail]] 
Sent: Saturday, June 16, 2012 4:34 PM
To: Jim Barnett
Cc: [e-mail]
Subject: Re: [rtcweb] Mute implementations (Re: More Comments
ondraft-ietf-rtcweb-use-cases-and-requirements-07)
 
On 06/16/2012 10:07 PM, Jim Barnett wrote:

	Harald,
	   Your description below makes me nervous:  with getUserMedia,
the 
	user grants permission to _specific_ media streams (for example
audio,

 

	or front camera, but not rear).

Yes, he grants permission to use of the camera. That permission persists
until <we have to define this point in time>. There's some interesting
language there now about "strong" and "weak" references to video
streams.
 

	   If the system wants " to change the source of a video stream
after 
	its creation", shouldn't it be required to ask permission again?
In 
	this case,  common sense says that it's not necessary, but
that's 
	because we're not changing to an arbitrary alternative the
source 
	(e.g., suddenly switching on the rear camera) but rather
substituting 
	some sort of 'null' or 'dummy' source.  Can we think of a
different 
	way to phrase it?

There are multiple ways to implement a requirement, as always.
 
One possibility is the simple one:
 
getUserMedia(..., function(strream) {
       outgoingstream = stream;
})
getStreamFromPicture(image, function(stream) {
       
outgoingstream.videoStreams(0).replaceContent(stream.videoStreams(0));
}..)
 
whatever the "replace" call does.
There may be a requirement that we keep a reference around that keeps
the video stream, so that we can restore it, in order that the camera
not close and can be used later:
 
getUserMedia(..., function(strream) {
       copyOfCameraStream = stream;
       outgoingstream = MediaStream(stream.audioTracks,
stream.videoTracks);
 
})
 
getStreamFromPicture(image, function(stream) {
       
outgoingstream.videoStreams(0).replaceContent(stream.videoStreams(0));
}..)
 
restorePicture = function() {
      
outgoingtstream.videoStreams(0).replaceContent(copyOfCameraStream.video.
Streams(0));
}
 
But there are surely multiple other ways to define it. What I want to
make sure we have done first is to capture the requirement accurately.
 

	 
	- Jim
	 
	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]]
On 
	Behalf Of Harald Alvestrand
	Sent: Saturday, June 16, 2012 3:56 PM
	To: [e-mail]
	Subject: Re: [rtcweb] Mute implementations (Re: More Comments
	ondraft-ietf-rtcweb-use-cases-and-requirements-07)
	 
	On 06/15/2012 11:18 PM, Randell Jesup wrote:

		On 6/15/2012 4:49 PM, Martin Thomson wrote:

			On 15 June 2012 13:42, Randell
Jesup<[e-mail]> <mailto:[e-mail]> 

wrote:

				I would also suggest that for video-mute
that instead of stopping 
				video or sending black, the application
should send a "mute image".

			The question I have is whether there is: a) a
fixed image/video that

 

			is serialized to RTP b) video "comfort noise",
or c) local mute 
			image/video playback.  If it can't be c, then
you might need to 
			explain yourself.

		Either we build it into the system (which I dislike -
SetMuteImage() 
		or whathaveyou, though we could), or we put it in the
application 
		domain and suggest or assist implementation.
		 
		The simple way to handle Mute is to revector the input
to a "mute" or

 

		"hold" source, and they may not be the same (hold would
have "Please 
		Hold" and music, perhaps; mute would have silence and
"Muted" or a 
		camera with a circle/slash, etc).  You can also signal
that out of 
		band to let the other end take smart action (remove
muted video 
		image, display "muted" next to a name, etc).  This can
be done via 
		DataChannels, for example.  You may then reinvite for
Hold to make it

 

		one-way, but that's mostly optional.

	The resulting requirements seem to me to be:
	 
	1) To be able to use a still image as source for a video stream
	2) To be able to change the source of a video stream after its 
	creation
	 
	Both are requirements on the GetUserMedia API. Can we link these
to a 
	specific use case, or do we need to modify the use case document
so 
	that the requirements are clear?
	 
	               Harald
	 
	 
	 
	 
	_______________________________________________
	rtcweb mailing list
	[e-mail]
	https://www.ietf.org/mailman/listinfo/rtcweb