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

[Harald Alvestrand <[e-mail]>]

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