minutes of first hour

     Media Capture Call

Minutes from last meeting approved without objection.

Dan Burnett:  New version of MediaCapture Document.  Travis' settings proposal
has been added.  The list of constraints is just a sample.  There was no agreement
in Boston about what set of constraints to add.  I focused on the framework
for changing constraints, not specific constraints.  Also added state 'new'
for Tracks.  Tracks can be created outside of a gUM call, so that's what the
'new' state is for.  If we keep this, we would need a started event to signal
when the Track moved from 'new' to actually sending media.  Also added an
'overconstrainted' event.  I plan to add some other things:  in Travis'
proposal there are attributes 'read-only' and 'remote'.   These effect
which constraints you can apply.  Also need to add capabilitiesa and states
(= the current setting).  We still need to discuss what the right set of
constraints is, and also whether gUM is synchronous or asynchronous, plus
its syntax.

Harald:  Do we need we need to keep the long section of examples?

Dan:  Yes, we will need it over the long term.  I plan to add it back.
Now we move to open discussion of constraints and settings.

Adam:  I will send examples showing how the API will look if we
don't have prepend/append methods.

Harald: I think it would look better to extract the JSON object, modify it
and then reset it.

Martin: I think that mandatory constraints are all we need. We have an overloaded state,
the muted state,  it would be better  to have two state objects.  Life cycle goes from new
to live to ended.  And this is orthogonal to whether the track is muted.  So it would be
good to separate them.

Stefan: It's obvious that 'enabled' and 'muted' not well explained and perhaps misnamed.
I think it makes sense to separate 'muted'.

Dan: So 'muted' is what the user does?

Martin:  Yes,  'muted' means that the user has hit a mute button (we can't always detect
this).

Dan: I'm not sure it's completely orthogonal.  You can't have a muted track that doesn't exit.
It doesn't make sense for ended or new to be muted.

Martin: I'll send a proposal to the list.

ekr: I don't see why we need append prepend.  JavaScript can handle this.

Travis:  Those were added for convenience, but we can rip them out if people don't see
the value.  If all you're doing is adding constraints, it makes it easy.  But you could
use a JS array, do your modifications, and then just apply it at the end.  All you need
to do is to get the initial state, and then modify it once you're done.

Dan: assign me an action to do this.

Adam: So I don't have to send my examples.

Stefan: Does anyone disagree with the overall direction?

Jim: It would be nice to pull constraints out into a separate partial interface
that other specs could inherit.

Adam: Yes, now is a good time to do it.

Dan: It's a good idea but I'm not sure how to do it.

Harald: It's fine if it's an exportable interface from this document.  Partial interfaces
don't have their own names.

Adam: You can use 'implements'.

Travis:  I can give you an example of how to do this.

Giri: I don't mind a 'constrainable' interface, but I have a problem with how they're defined.
Constraints are supposed to live on the track, but that may not make sense for recording or image
capture.  Width/Height in recording is just a one-time thing, it doesn' necessarily affect the
constraints on the Track.

Travis:  The constraints affect the data that flow through the track. But image capture and
recording are sinks, but we want to apply the same mental model.  These apply in addition
to what the tracks are doing.  Or we could come up with a new system specially for sinks.

Jim:  I think that the constraints apply to the object that implements the interface, not
necessarily the underlying tracks.  So for recording the constraints apply to the MediaRecorder
object, not the Tracks.  The spec will have to define the exact semantics.

Giri: That makes more sense.

Dan: This is what I've always had in mind.  I'll have to make sure that the definition is
general enough.

Adam: It's tricker to add it to PeerConnection, but it needs the concept as well.

Giri:  Is the IANA registry applicable. Will all specs adopt the IANA registry?

Travis: I don't see why not.  On the other hand, should the specs define the list
of constraints, or do we just link to an external registry?

Dan:  A W3C specification can define new entries for the IANA registry.  So the spec
defines the entries, and can specify that they are to be added to the registry.  So
it all gets done in one place.

Harald:  Enumerating devices.  I suggest that we return a list of attributes, and return only
the ones that the app is allowed to see.  When app is allowed to see the cameras, it gets the
labels of all the cameras.  This exposes no more information and makes it easier to develop interface
as long as we get the permissions correctly.

Martin:  I like this.  But if you grant permission for one camera, do you get labels for all cameras?

Harald: No.

Adam: When you give access to all cameras, does the Stream have several audio and video tracks, or
is it first camera, first audio stream?

Harald: If you call gUM without further specification, you get the default camera.

Dan: A request for a camera shouldn't return all the cameras, even if the user gives permission
for all devices.  It should return one.

Adam: If you have already given permission for all cameras, why call gUM again?

Harald:  No new question would get asked to user.  It was as if you had stored permissions.

EKR:  It seems to me is all I can do is ask for a camera, then enumerate them. How do I ask
for a specific one.

Harald: App does something that causes permission request.  You get a camera.  You can then ask
for a list of all cameras, and you get all the ones the user has given permission to.

Travis:  The most effective strategy is to show the user what the camera is showing and let him pick.
The names don't convery much information.

EKR:  I'm confused about the implied permission model.  If I do gUM and it's not a persistent permission.
If I close the Stream and open a new one, do I get a camera?

Harald: Yes, I see the problem.  The app can open a camera later without asking and that can be
a problem.

Travis:  Is the goal to put the persistence model in the spec?

EKR: The ietf spec says that there is a difference between persistent and non-persistent permissions.
Right now Chrome has only persistent constraints, and Firefox has only termporary ones.  It's useful
to the app to 1) be able to ask for what it had last time  b) to show the user what he's going to get.

Harald: I've found that people learn to recognize the camera labels.

Adam: Is it up to the script to show the preview?  Shouldn't the browser chrome handle this?

EKR: Good point.

Adam: We used to have a stop method on a local media stream, which let the app revoke its permissions.
We should support this.

Dan: It's still there, but it's on Tracks.

Adam: If you ask with the same source ID, you don't automatically get the camera.  May need to call
gUM again.

Dan: Stop is not on the source, but on the Tracks.  So this is different from revoking a permission
that you have for a Source.

Harald:  I will come up with an illustrative example, and we'll discuss it on the list.

Stefan: Additional issues should be filed as bugs.  Proposals for new features should be taken to the
list.