Re: [Bug 22338] New: Arbitrary changing of tracks

On 17 June 2013 05:39, Harald Alvestrand <harald@alvestrand.no> wrote:
>> The spec permits a user or user agent to switch between tracks at any time:
>>
>> Unless and until a new set of constraints is provided, the user agent MAY
>> change its choice of track at any point, provided that 1) the new choice
>> does
>> not violate given user permissions, and 2) it notifies the application code
>> by
>> raising an event.
>
>> The event is undefined, but that's not the concern.  As a user, I don't want
>> this to happen.  Therefore, as an application developer, I don't want this
>> to
>> happen.  If this is possible (it sounds like a bad idea to me), there needs
>> to
>> be a way to prevent it from happening.
>
>> sourceId constraints are not sufficient.
>
> Martin, can you be a little more precise in what you mean here?
>
> What do you mean by "user or user agent", and what do you mean by "switch
> between tracks"?

>From the text, I infer that a user agent could, if it deemed it to be
most appropriate at the time, switch between two cameras at arbitrary
times.  This might be an autonomous action by the user agent, or at
the behest of the user.

The actor is either the user or the user agent, but the two are
indistinguishable at the application-level - and the implication is
that there is no ability to control or prevent this switch.  As an
application developer, I might not want this happening without my
involvement.  Perhaps I'd rather that a stream die than have
everything change under me.

As a user, I really don't want the browser making this switch.  If my
browser suddenly decides that my butt camera is the best choice, then
I'd like to have a chance to put some pants on.

> One scenario for use of multiple tracks in a video stream that has been
> suggested is to send both a video and an "on-hold image" as two video
> tracks, and implement "video mute" by disabling the video track while
> enabling the "on-hold image" track - which allows one to achieve the effect
> without changing the source of the video element displaying the stream. On
> first thought, I wouldn't see a reason to disallow that.

The switch to a "video mute" still should be an application choice.
The black that is sent when there is nothing to send should be just
that - the user agent shouldn't need to do more than that.

> One scenario I've heard (but which I don't think anyone's implemented yet)
> is that the user might switch cameras or microphones by some interaction
> with browser chrome rather than causing the application to getUserMedia
> again. I wouldn't be too concerned if that functionality were to go away -
> but again, I don't see a strong argument against it at the moment.

That is perfectly reasonable scenario.  One that I might, as an
application developer be OK with allowing.

But again, it's the user, not the user agent.  I can't imagine
building a user agent that was inconsistent in this way.

As I think more about this, it might be possible to set a sourceId
constraint after getting a stream.  That might solve the problem.
Either way, there's something to do with the spec, even if it's just
informative.

Received on Monday, 17 June 2013 21:20:02 UTC