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

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

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

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