Media Capture Task Force Teleconference

<stefanh> minutes from last meeting: http://lists.w3.org/Archives/Public/public-media-capture/2013Feb/0034.html

<dom> Minutes from Boston F2F

RESOLUTION: Minutes from last meeting approved without objection.

Media Capture and Streams: constraints and settings

<stefanh> Dan's slides; http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/att-0086/ConstraintChanges20130325.pdf

<dom> Media Capture and Streams Editors draft

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?

<stefanh> (this is what Harald talked about: https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html#track-constraints)

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.

<dom> Proposed constraints list (not reflecting consensus yet)

<dom> Getting and setting constraints on MediaStreamTrack

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

<hta> ACTION: Adam to Send out an illustration on how things would look if the modification operations are done on a separate object. [recorded in http://www.w3.org/2013/03/25-mediacap-minutes.html#action01]

<trackbot> Created ACTION-17 - Send out an illustration on how things would look if the modification operations are done on a separate object. [on Adam Bergkvist - due 2013-04-01].

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

<martin_> for later discussion: we should discuss the orthogonality of stream/track lifecycle and muting state

<dom> source and constraints in terminology section

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.

<hta> ACTION: martin to send state diagram to the list with muted/enabled/disabled/ended states [recorded in http://www.w3.org/2013/03/25-mediacap-minutes.html#action02]

<trackbot> Created ACTION-18 - Send state diagram to the list with muted/enabled/disabled/ended states [on Martin Thomson - due 2013-04-01].

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.

<hta> ACTION: burnett to Remove append and prepend operations from track. [recorded in http://www.w3.org/2013/03/25-mediacap-minutes.html#action03]

<trackbot> Created ACTION-19 - Remove append and prepend operations from track. [on Daniel Burnett - due 2013-04-01].

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.

<dom> [NoInterfaceObject] interface Constrainable { };

<martin_> duck-type: foo implements bar;

<dom> MediaStreamTrack implements Constrainable;

<martin_> as opposed to inheritance: bar extends foo {};

<hta> ACTION: travis to Send a proposal on how to extract constrainable to a separate interface. [recorded in http://www.w3.org/2013/03/25-mediacap-minutes.html#action04]

<trackbot> Created ACTION-20 - Send a proposal on how to extract constrainable to a separate interface. [on Travis Leithead - due 2013-04-01].

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.

Media Capture and Streams: device enumeration

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.

<stefanh> Haralds input: http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0050.html

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.

<martin_> +1 to burn: the user can grant more than is actually returned

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.

<martin_> I think that I'm against the idea of signaling to the browser that you want persistent permissions. What does the browser do differently? What motivates an app to do anything other than persistent requests?

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.

<ekr> +1 to HTA

<hta> ACTION: hta to Come up with an illustrative usage of the proposed functionality. [recorded in http://www.w3.org/2013/03/25-mediacap-minutes.html#action05]

<trackbot> Created ACTION-21 - Come up with an illustrative usage of the proposed functionality. [on Harald Alvestrand - due 2013-04-01].

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

<ekr> Even ignoring the permissions question, I think it's important for the JS to have some easy way of making the green light go off

<ekr> And it's not awesome if that's a side effect of JS garbage collection

<ekr> This isn't a security issue solely, just something that makes people sad

<ekr> I think I am hearing that .stop() only acts on tracks and not sources

MediaStream Recording

<scribe> scribe: Travis

JIM: Updated recording spec with some feedback; API name changes, etc.

<dom> Updated draft of MediaStream Recording

burn: I included takePhoto as part of the track--it needs to align with Giri's doc as appropriate.

<ekr> is localmediastream even in the current doucment

JIM: We've been discussing error handling. Thinking about using some base error class and extending it...
... to avoid defining a bunch of new classes with no real additional functionality.

<hta> ekr: no, stop() has moved to track.

JIM: hta: was supposed to come up with a proposal?
... We'll talk about this later than.

hta: No, haven't made that proposal yet.
... hearing no consent, please publish an updated draft.

stefanh: send mail to the list when done.
... Topic: Image capture draft.

<hta> ACTION: jim to republish recording draft without the photo methods. [recorded in http://www.w3.org/2013/03/25-mediacap-minutes.html#action06]

<trackbot> Created ACTION-22 - Republish recording draft without the photo methods. [on James Barnett - due 2013-04-01].

<dom> Latest Image Capture draft

<dom> frameGrabber method

<Travis_> ... put out another version to make the spec work with a "constrainable" interface.

gmandyam: [discussion on frame-loss versus loss-less design approaches]

<hta> Resolution: getFrame doesn't return until there's new data available (newer than what came back in a previous getFrame).

travis: Jim: we should ensure we have a way to meet the loss-less frame-grabber scenario in media recorder API

stefanh: Wanted a task force last call in 2nd Quarter for official last call.

ekr: Lot of work still to get to that point.

dom: would be useful for all members to send to the list what they think needs to be in the draft before LC.

stefanh: Everyone please put your time/energy into helping get the spec updated/reviewed.
... That's it for the agenda items...
... anything else?