- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 02 Apr 2013 13:49:37 +0200
- To: public-media-capture@w3.org
Hi,
The minutes of our call last Monday are now available at:
http://www.w3.org/2013/03/25-mediacap-minutes.html
and copied as text below.
Dom
Media Capture Task Force Teleconference
25 Mar 2013
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0039.html
See also: [3]IRC log
[3] http://www.w3.org/2013/03/25-mediacap-irc
Attendees
Present
Dan_Burnett, +91.22.39.14.aaaa, stefanh, dom, hta,
gmandyam, adambe, Jim_Barnett, martin___, ekr, fjh,
+33.2.31.26.aaff, Travis, [Mozilla],
Regrets
Chair
stefanh, hta
Scribe
JimB, Travis
Contents
* [4]Topics
+ [5]Media Capture and Streams: constraints and settings
+ [6]Media Capture and Streams: device enumeration
+ [7]MediaStream recording
* [8]Summary of Action Items
__________________________________________________________
<stefanh> minutes from last meeting:
[9]http://lists.w3.org/Archives/Public/public-media-capture/201
3Feb/0034.html
[9]
http://lists.w3.org/Archives/Public/public-media-capture/2013Feb/0034.html
<dom> [10]Minutes from Boston F2F
[10]
http://lists.w3.org/Archives/Public/public-media-capture/2013Feb/0034.html
RESOLUTION: Minutes from last meeting approved without
objection.
Media Capture and Streams: constraints and settings
<stefanh> Dan's slides;
[11]http://lists.w3.org/Archives/Public/public-media-capture/20
13Mar/att-0086/ConstraintChanges20130325.pdf
[11]
http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/att-0086/ConstraintChanges20130325.pdf
<dom> [12]Media Capture and Streams Editors draft
[12] http://dev.w3.org/2011/webrtc/editor/getusermedia.html
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:
[13]https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-captur
e/proposals/SettingsAPI_proposal_v6.html#track-constraints)
[13]
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> [14]Proposed constraints list (not reflecting consensus
yet)
[14]
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#constraint-registrations
<dom> [15]Getting and setting constraints on MediaStreamTrack
[15]
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#widl-MediaStreamTrack-constraints-MediaTrackConstraints
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
[16]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> [17]source and constraints in terminology section
[17]
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#terminology
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
[18]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
[19]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
[20]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:
[21]http://lists.w3.org/Archives/Public/public-media-capture/20
13Mar/0050.html
[21]
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
[22]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> [23]Updated draft of MediaStream Recording
[23]
http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/att-0063/MediaRecorderRespec.html
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
[24]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> [25]Latest Image Capture draft
[25]
http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/att-0019/Mediastream_Image_Capture.htm
<dom> [26]frameGrabber method
[26]
http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/att-0019/Mediastream_Image_Capture.htm#widl-ImageCapture-frameGrabber-void
<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?
Summary of Action Items
[NEW] ACTION: Adam to Send out an illustration on how things
would look if the modification operations are done on a
separate object. [recorded in
[27]http://www.w3.org/2013/03/25-mediacap-minutes.html#action01
]
[NEW] ACTION: burnett to Remove append and prepend operations
from track. [recorded in
[28]http://www.w3.org/2013/03/25-mediacap-minutes.html#action03
]
[NEW] ACTION: hta to Come up with an illustrative usage of the
proposed functionality. [recorded in
[29]http://www.w3.org/2013/03/25-mediacap-minutes.html#action05
]
[NEW] ACTION: jim to republish recording draft without the
photo methods. [recorded in
[30]http://www.w3.org/2013/03/25-mediacap-minutes.html#action06
]
[NEW] ACTION: martin to send state diagram to the list with
muted/enabled/disabled/ended states [recorded in
[31]http://www.w3.org/2013/03/25-mediacap-minutes.html#action02
]
[NEW] ACTION: travis to Send a proposal on how to extract
constrainable to a separate interface. [recorded in
[32]http://www.w3.org/2013/03/25-mediacap-minutes.html#action04
]
[End of minutes]
Received on Tuesday, 2 April 2013 11:49:52 UTC