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

["Sunyang (Eric)" <[e-mail]>]

Do we need add one more scenario:

The same video B2B communication, and switch video stream between front and rear webcam?
The video streams displayed in the same video element, but source changed.

There is on relative scenario in media capture scenarios, “video diary….”, but not not related with above mentioned scenario.

Should we add it?

发件人: [e-mail] [mailto:[e-mail]] 代表 Harald Alvestrand
发送时间: 2012年6月17日 16:01
收件人: Jim Barnett
抄送: [e-mail]
主题: 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.html



  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]<mailto:[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]> [mailto:[e-mail]] On

Behalf Of Harald Alvestrand

Sent: Saturday, June 16, 2012 3:56 PM

To: [e-mail]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/rtcweb