W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

[minutes] March 25 teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 02 Apr 2013 13:49:37 +0200
Message-ID: <1364903377.11010.8.camel@cumulustier>
To: public-media-capture@w3.org

The minutes of our call last Monday are now available at:

and copied as text below.


                Media Capture Task Force Teleconference

25 Mar 2013



   See also: [3]IRC log

      [3] http://www.w3.org/2013/03/25-mediacap-irc


          Dan_Burnett, +, stefanh, dom, hta,
          gmandyam, adambe, Jim_Barnett, martin___, ekr, fjh,
          +, Travis, [Mozilla],

          stefanh, hta

          JimB, Travis


     * [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:


   <dom> [10]Minutes from Boston F2F


   RESOLUTION: Minutes from last meeting approved without

Media Capture and Streams: constraints and settings

   <stefanh> Dan's slides;


   <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

   <stefanh> (this is what Harald talked about:


   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

   <dom> [14]Proposed constraints list (not reflecting consensus


   <dom> [15]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

   <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


   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

   <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

   <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

   <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

   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:


   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

   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

   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

   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

   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

   <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


   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

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

   <dom> [25]Latest Image Capture draft


   <dom> [26]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

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

   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
   [NEW] ACTION: burnett to Remove append and prepend operations
   from track. [recorded in
   [NEW] ACTION: hta to Come up with an illustrative usage of the
   proposed functionality. [recorded in
   [NEW] ACTION: jim to republish recording draft without the
   photo methods. [recorded in
   [NEW] ACTION: martin to send state diagram to the list with
   muted/enabled/disabled/ended states [recorded in
   [NEW] ACTION: travis to Send a proposal on how to extract
   constrainable to a separate interface. [recorded in

   [End of minutes]
Received on Tuesday, 2 April 2013 11:49:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC