W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2012

Re: [minutes] April 10 teleconf

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 11 Apr 2012 09:55:13 +0200
Message-ID: <4F8538E1.1030702@ericsson.com>
To: Dominique Hazael-Massieux <dom@w3.org>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Great job scribing Justin and Dom.

Commented my @@@ inline.

/Adam

On 2012-04-11 09:01, Dominique Hazael-Massieux wrote:
> Hi,
>
> The minutes of our teleconf yesterday are available at:
> http://www.w3.org/2012/04/10-webrtc-minutes.html
> linked from http://www.w3.org/2011/04/webrtc/#meeting
>
> There are a couple of points that I missed when I scribed noted as
> "@@@", from Adam and Justin; let me know if you remember what was said
> then.
>
> Text version of the minutes below.
>
> Dom
>
>         Web Real-Time Communications Working Group Teleconference
>
> 10 Apr 2012
>
>     [2]Agenda
>
>        [2]
> http://lists.w3.org/Archives/Public/public-webrtc/2012Apr/0003.html
>
>     See also: [3]IRC log
>
>        [3] http://www.w3.org/2012/04/10-webrtc-irc
>
> Attendees
>
>     Present
>            +1.403.244.aaaa, Dan_Burnett, Cullen_Jennings,
>            Jim_Barnett, +1.415.800.aabb, dom, +46.1.07.14.aacc,
>            stefanh, +46.1.07.14.aadd, adambe, +1.908.541.aaee,
>            +1.650.961.aaff, +1.415.800.aagg, anant, derf,
>            Dan_Druta, +1.610.889.aahh, +33.6.85.56.aaii, jesup,
>            +47.41.44.aajj, hta, nstratford, +1.617.575.aakk,
>            juberti, +1.408.902.aall, +1.650.678.aamm, Narm_Gadiraju
>
>     Regrets
>     Chair
>            Stefan_Hakansson, Harald_Alvestrand
>
>     Scribe
>            juberti, dom
>
> Contents
>
>       * [4]Topics
>           1. [5]Minutes approval
>           2. [6]Action items
>           3. [7]F2F meetings
>           4. [8]Media Capture
>           5. [9]Audio WG feedback request
>           6. [10]Spec status
>           7. [11]JSEP API
>       * [12]Summary of Action Items
>       __________________________________________________________
>
>     <fluffy>  I joined the call but unfortunately I am in another
>     meeting for the first part of this.
>
>     <anant>  I will have to take my leave at 9am, unfortunately
>
>     <dom>  scribenick: juberti
>
>     stefan: agenda review
>     ... audio WG request for review
>     ... status of the spec
>     ... any other business
>
>     <jesup>  Does someone have a URL for the audio WG request for
>     Review?
>
> Minutes approval
>
>     <dom>  [13]March 13 minutes
>
>       [13] http://www.w3.org/2012/03/13-webrtc-minutes.html
>
>     stefan: first action - approve minutes from last meeting
>
>     hta: if no objections, they are approved
>
>     <dom>  jesup,
>     [14]http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0
>     072.html
>
>       [14]
> http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0072.html
>
>     <dom>  [15]Open Action items
>
>       [15] http://www.w3.org/2011/04/webrtc/track/actions/open
>
> Action items
>
>     stefan: review open actions
>
>     <dom>  ACTION-11?
>
>     <trackbot>  ACTION-11 -- Daniel Burnett to add Hints API to API
>     spec -- due 2012-01-12 -- OPEN
>
>     <trackbot>
>     [16]http://www.w3.org/2011/04/webrtc/track/actions/11
>
>       [16] http://www.w3.org/2011/04/webrtc/track/actions/11
>
>     hta: Constraints API status
>
>     dan: proposal, hasn't been added to spec, not sure if we have
>     consensus
>
>     hta: want to send note to Media Capture task force saying we
>     have sufficient consensus
>
>     <dom>  ACTION-11:
>     [17]http://lists.w3.org/Archives/Public/public-media-capture/20
>     12Mar/0033.html Constraints and Capabilities API for
>     getUserMedia
>
>       [17]
> http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html
>
>     <trackbot>  ACTION-11 Add Constraints API to API spec notes
>     added
>
>     <dom>  ACTION-13:
>     [18]http://lists.w3.org/Archives/Public/public-media-capture/20
>     12Mar/0033.html Constraints and Capabilities API for
>     getUserMedia
>
>       [18]
> http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html
>
>     <trackbot>  ACTION-13 Add Capabilities API to API spec notes
>     added
>
>     <dom>  ACTION-12?
>
>     <trackbot>  ACTION-12 -- Daniel Burnett to add Stats API to API
>     spec -- due 2012-01-20 -- OPEN
>
>     <trackbot>
>     [19]http://www.w3.org/2011/04/webrtc/track/actions/12
>
>       [19] http://www.w3.org/2011/04/webrtc/track/actions/12
>
>     dan: no progress on stats API
>
>     <dom>  ACTION-18?
>
>     <trackbot>  ACTION-18 -- Stefan Håkansson to contact Web and
>     TV/Media TF to understand if their reqs and views of
>     MediaStreams and Tracks is similar -- due 2011-11-16 -- OPEN
>
>     <trackbot>
>     [20]http://www.w3.org/2011/04/webrtc/track/actions/18
>
>       [20] http://www.w3.org/2011/04/webrtc/track/actions/18
>
>     <dom>  [21]Any overlap with webrtc WG?, Stefan Hakansson LK on
>     March 20
>
>       [21]
> http://lists.w3.org/Archives/Public/public-web-and-tv/2012Mar/0031.html
>
>     stefan: don't think there are they many similarities, Stefan
>     will follow up and see if there is any overlap
>
>     <dom>  ACTION-18: see
>     [22]http://lists.w3.org/Archives/Public/public-web-and-tv/2012M
>     ar/0031.html
>
>       [22]
> http://lists.w3.org/Archives/Public/public-web-and-tv/2012Mar/0031.html
>
>     <trackbot>  ACTION-18 Contact Web and TV/Media TF to understand
>     if their reqs and views of MediaStreams and Tracks is similar
>     notes added
>
>     hta: changing numeric constants to be strings
>
>     dan: remind me what this is?
>
>     <dom>  ACTION-29?
>
>     <trackbot>  ACTION-29 -- Daniel Burnett to change all numeric
>     constants to be enumerated strings -- due 2012-04-01 -- OPEN
>
>     <trackbot>
>     [23]http://www.w3.org/2011/04/webrtc/track/actions/29
>
>       [23] http://www.w3.org/2011/04/webrtc/track/actions/29
>
>     hta: stop using numeric enums, switch to using strings
>
>     dan: don't remember the specifics of this
>
>     hta: cullen did this in his draft JSEP proposal
>     ... dan, will follow up with you on this one
>     ... echo cancellation API - is cullen here?
>     ... proposed moving mediastream API from PeerConnection to
>     getUserMedia
>     ... recent discussion on getting adam/cullen/justin together to
>     discuss JSEP API
>     ... end of action list
>
> F2F meetings
>
>     stefan: next task is to discuss upcoming f2f meetings
>     ... proposal is to do back-to-back with upcoming IETF interim
>     meeting
>
>     adambe: where will this meeting be located?
>
>     <jesup>  SFO, NYC, BOS, London, STockholm
>
>     <anant>  burn, just for reference, ACTION-29 refers to changing
>     all the 'const' as listed in
>     [24]http://dev.w3.org/2011/webrtc/editor/webrtc.html#peerconnec
>     tion to strings
>
>       [24]
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#peerconnection
>
>     <dom>  [25]Doodle for picking dates for next RTCWeb meeting
>
>       [25] http://doodle.com/nm3pp69znr3286cy
>
>     hta: not sure yet - SFO, NYC, BOS, STO
>
>     anant: how will the venue be chosen?
>
>     hta: no specific procedure
>
>     anant: can't really fill out the doodle poll until we know what
>     venue will be chosen
>
>     hta: doodle poll closes this friday
>
>     stefan: next f2f is TPAC in October
>
>     hta: interacting with DAP WG and Media Task Force
>
>     <dom>  (for the May/June F2F, have we decided for how long? how
>     it would relate to the IETF meeting?)
>
>     stefan: so we should aim to have our meetings on the same days
>
>     dom: would we have 1 day for the W3C f2f?
>
>     stefan: I think the IETF f2f would be 2 days, so the W3C would
>     be just before or after
>
>     hta: I think 0.5 days was too short the last time, this time
>     we'll do a whole day
>     ... any comments?
>
>     stefan: next thing on the agenda
>
> Media Capture
>
>     stefan: chairs to report on Media Capture Task Force
>     ... anant has made many proposals for changes and updates
>     ... not much feedback to date. Would like to see more feedback
>     from this community.
>     ... hta, anything from your side?
>
>     anant: proposed changes to getUserMedia spec, but only 2-3
>     people responding
>
>     stefan: should we move the definition of MediaStream into the
>     getUserMedia specification?
>
>     anant: you could still have a MediaStream even outside of
>     PeerConnection
>     ... OTOH, PeerConnections have specific mappings to RTP streams
>
>     <dom>  +1 on moving MediaStream to getUserMedia
>
>     anant: so need to figure out where this should go
>     ... I lean towards putting it in getUserMedia
>     ... define the base MediaStream stuff in getUserMedia doc,
>     extensions for realtime usage can go into PeerConnection doc
>
>     dom: I think we'll see getUserMedia show up in browsers sooner
>     than PeerConnection, so I think MediaStream should go in that
>     spec
>
>     juberti: How would we do this split?
>
>     anant: An example could be attributes on the MediaStream for
>     packet loss
>     ... which is only relevant to PeerConnection
>
>     <jesup>  Seems reasonable to move it to me.
>
>     suhas: Can we make a standalone for for MediaStream?
>
>     anant: we could, but there is overhead - I don't see a case
>     where getUserMedia has stuff that isn't needed in the general
>     case
>
>     hta: no real dissent voiced
>
>     <jesup>  Robert O'Callahan's MediaStream Processing spec also
>     extends MediaStreams slightly - adds currentTime,
>     createProcessor(), createWorkerProcessor()
>
>     juberti: I agree that getUserMedia will ship sooner and also be
>     unlikely to have things that aren't generally useful
>
>     stefan: I agree with this direction
>
>     someone: could we get dropped frames info from the MediaStream?
>
>     jesup: what about stats tied to data in the stream
>
>     hta: decision to move the spec as described
>
>     <hta>  ACTION: anant to move MediaStream spec to getUserMedia
>     [recorded in
>     [26]http://www.w3.org/2012/04/10-webrtc-minutes.html#action01]
>
>     <trackbot>  Created ACTION-38 - Move MediaStream spec to
>     getUserMedia [on Anant Narayanan - due 2012-04-17].
>
>     <jesup>  We can extend MediaStream in WebRTC (as we already do
>     for localMediaStreams)
>
> Audio WG feedback request
>
>     stefan: audio WG sent request for review of their spec to the
>     WebRTC list
>
>     <dom>  [27]Audio WG request for feedback
>
>       [27]
> http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0072.html
>
>     stefan: not sure if we should accumulate group feedback versus
>     individual feedback. what do people think?
>
>     jesup: there are some competing proposals
>     ... proposal from Mozilla ties audio processing/video
>     processing more closely with MediaStreams
>
>     hta: one piece of feedback is that we would like to only have
>     to evaluate one proposal
>
>     derf: haven't seen satisfactory answers to the concerns that
>     have been raised for real-time usage
>
>     jesup: would be nice to process audio streams and video streams
>     in the same framework
>     ... but it doesn't do this right now
>
>     derf: proposal doesn't handle synchronization
>
>     stefan: suggestion is to do individual feedback
>
>     <jesup>  Synchronization is critical to WebRTC
>
>     <dom>  scribenick: dom
>
> Spec status
>
>     hta: JSEP aligned API - status?
>
>     stefanh: should we wait for cullen to join the call?
>     ... he said he would be late
>
>     hta: let's wait and see
>     ... let's move to Data API
>
>     dom: regarding constraints, I was suggesting this should be
>     done separately from getUserMedia
>     ... due again to the difference in release schedule for that
>     feature
>     ... getUserMedia will be shipped without constraints at first
>     ... so contraints should be spec-d separately
>     ... with the proper hook
>
>     Dan: I definitely see the need to be able to say "I want a
>     video stream" independently of constraint
>     ... but I'm a bit nervous about saying we'll deal with
>     constraints later
>     ... constraints are also useful for local user media
>     ... e.g. screen resolutions
>     ... there may be a need to actually specific some constraints
>     that are camera-related
>
>     <jesup>  Agreed on screen resolutions, frame rate, etc
>
>     Dan: some people have a notion of a logical media stream
>     ... the encoding e.g. depends on the resolution
>     ... so that dependency makes me nervous
>
>     hta: a logical way forward is to have a place where to list
>     constraints, without specifying constraints
>
>     dan: I would prefer that
>     ... as a group, we'll need to define what set of constraints we
>     want to proceed with
>     ... this may be an empty set
>     ... e.g. no constraints may be necessary for the local case
>
>     Randell: this seems reasonable to me
>     ... this also exposes the fact that we haven't talked about how
>     to modify the parameters of a source after having obtained it
>     from getUserMEdia
>     ... e.G. changing resolution of framerate from an existing
>     stream
>     ... at this time, the only way to do that is to get a different
>     getUserMedia stream
>     ... I would think you would want to be able to modify the
>     stream you're getting
>
>     dan: so you're thinking we could still use constraints but it
>     would be a new set of constraints that would replace the
>     existing ones on an existing stream
>     ... I don't know if that cover all cases, but it covers some of
>     them for sure
>     ... that means you don't have to drop your stream to get a new
>     one
>     ... you want to make sure you don't tear down a number of
>     states that would have to be rebuilt
>     ... some constraints would not require a new permission check;
>     some might
>     ... but that doesn't mean we wouldn't want to make that kind of
>     modification
>
>     dom: no question about the need for constraints, but clearly
>     this adds complexity, possible another API for modifying
>     streams
>     ... all of which is unlikely to be shipped as early as
>     getUserMedia
>     ... so we should focus on getUserMedia first, constraints later
>
>     dan: Adam's proposal might be acceptable with me; but if we do
>     start adding hints as others have suggested, then I want to
>     have constraints added in the first phase
>     ... since hints are exactly what constraints are supposed to
>     address
>     ... rich has been suggesting having hints
>
>     randell: e.g. a way to express preference of resolution vs
>     framerate
>
>     justin: we have specific use cases of what we want to do
>     ... if we don't think that hints solve our use cases, then that
>     doesn't seem like a worthy proposal
>
>     stefanh: hints seems to be equivalent to optional constraints
>
>     randell: I haven't thought enough about this; I don't have an
>     opinion on the matter at this point
>
>     hta: I haven't see any evidence that hints would differ from
>     optional constraints
>
>     dan: so it sounds like there is agreement for the people on
>     this call that any request for hints can most likely be
>     satisfied with a constraints structure
>     ... not working on constraints might work if we don't get hints
>     back in
>     ... how would this work in practice?
>     ... Adam's proposal wasn't to do away with constraints
>
>     Adam: my proposal was to add the constraints object as a third
>     property of the first param in getUserMedia
>     ... to break the dependency between getUserMedia and
>     constraints definitions
>
>     <anant>  I apologize, I have to leave for another meeting that
>     starts in 5 minutes, I will review minutes later to see what I
>     missed.
>
>     <fluffy>  I have joined the call again
>
>     dom: my idea was not to stop work on constraints, but move it
>     to a parallel work item with less attention from the group
>     ... we probably need to look a concrete integration proposals
>     off-line
>     ... but the idea was that constraints would be a third property
>     in the mediastreamoptions object
>     ... that browsers should block on if they can't interpret it
>
>     dan: that sounds like fine if we agree on the dictionary
>     structure
>     ... the "fail on unknown" constraint sounds like approach to
>     forward-compatibility
>
>     cullen: given that audio and video are completely trivial to
>     specify, shouldn't we just do that?
>
>     dom: it's a bit hard to follow these suggestions without
>     concrete proposals
>
>     justin: shipping getUserMEdia with just VGA resolution would be
>     very useful
>
>     Adam: @@@

I think you can remove this entry Dom. If I remember correctly I was 
going to talk about features vs. time in the first release (noted below) 
but backed off when Dan started talking.

>     Dan: I don't think the group will agree that VGA only is the
>     right way to start
>
>     Adam: if the options is getting VGA in two months or wait
>     another year for other options, people will want VGA first
>
>     Justin: I'm not sure that getting resolutions right is that
>     trivial, so it would probably take a while
>
>     Cullen: my only proposal that selecting audio and video streams
>     would themselves be designed as constraints
>
>     Randell: I'm concerned that we spend a lot of time about
>     designing an API for setting static parameters
>     ... sounds like we're missing a big aspect of this
>     ... The solution might not be to design a overall constraints
>     API right now
>     ... but rather to define a way to have a way to change the
>     parameters of an existing media stream
>     ... then we don't have to solve the issue at the
>     "creation-time"
>
>     Dan: I see the two as the same problem
>     ... the constraints approach has two usefulness: don't do
>     anything if I don't get this; how strongly the dev cares about
>     a particular setting
>
>     Randell: yes, but it's not obvious that this needs to be hard
>     set in the algorithm in the spec
>     ... rather than by code in the Web app itself
>
>     Cullen: this is not a constraint language by any definition
>
>     <adambe>  yes
>
>     EKR: what are you allowed to say in this language? I've only
>     skimmed it some time ago
>
>     dan: it allows you to set min/max values for a number of
>     properties (e.g. aspect ratio, framerate, ...)
>
>     EKR: will this metastasized?
>     ... how can someone express something that hasn't been defined?
>
>     Randell: let's take a video source that has an embedded encoder
>     in it
>     ... that means you would have to specify constraint for that
>     encoder as well
>
>     dan: as an app dev, you only have to specify what you care
>     about
>     ... The browser will have to work out how to satisfy your
>     requirements
>
>     Randell: you're defining a constraints language for this, and
>     say that the app developer only has to deal with this if he
>     cares about it
>     ... but what if he cares? how does he deal with that case?
>
>     dan: I don't know that we can avoid the lower level code in
>     that case
>     ... constraints allow for a high level approach for most
>     developers needs
>
>     Randell: I don't have a problem with defining a constraint
>     language if we want one
>     ... if it convers everything we need
>     ... but I don't want it to forbid getting access to important
>     things that applications will want to access, e.g. setting
>     resolution
>     ... we can get by without it, but the pressure to get it will
>     be high
>
>     justin: not sure why VGA won't be sufficient for v1?
>
>     Cullen: mobile won't do it
>
>     justin: this could be the highest thing to ask for
>
>     hta: this is a more detailed discussion than we have had on the
>     list
>     ... With 15 minutes left, we need to return to JSEP
>
>     justin: it seems reasonable to have an initial constraint, plus
>     an API to change constraints
>
>     dan: the proposal was never to suggest we shouldn't let change
>     constraints
>     ... the proposal only gives examples of constraints; we would
>     need to define the first set of constraints
>     ... All of these are great discussions points: what constraints
>     in the first version? how can we change streams along the way?
>     can it be done using the same API?
>     ... i.e. using the same data structure
>
>     dom: how do we move forward with this?
>
>     hta: any action items?
>     ... earlier in the call there was an action item about
>     incorporating capabilities in the editors draft of getUserMedia
>
>     dan: there are some modifications that I need to bring to my
>     proposal based on what Adam proposed; or maybe based on
>     Cullen's proposal
>     ... I'm happy to do that and send an updated proposal
>     ... please read it then :)
>
>     hta: so Adam and Cullen, will you suggest modifications to
>     Dan's proposal?
>
>     dan: Adam already did
>     ... although you referenced the registry rather than my
>     proposal
>
>     <scribe>  ACTION: Dan to send an updated Capabilities proposal
>     to Media Capture Task Force [recorded in
>     [28]http://www.w3.org/2012/04/10-webrtc-minutes.html#action02]
>
>     <trackbot>  Sorry, amibiguous username (more than one match) -
>     Dan
>
>     <trackbot>  Try using a different identifier, such as family
>     name or username (eg. ddruta, dburnett, dromasca)
>
>     <scribe>  ACTION: burnett to send an updated Capabilities
>     proposal to Media Capture Task Force [recorded in
>     [29]http://www.w3.org/2012/04/10-webrtc-minutes.html#action03]
>
>     <trackbot>  Created ACTION-39 - Send an updated Capabilities
>     proposal to Media Capture Task Force [on Daniel Burnett - due
>     2012-04-17].
>
> JSEP API
>
>     stefanh: we've only had limited feedback on which of the
>     proposals for moving forward with JSEP
>
>     cullen: current status is that we're trying to find a time with
>     Justin, Adam and me to discuss our proposals in more details
>     ... I've always characterized the two proposals by the number
>     of function calls
>     ... but this was a flawed understanding apparently
>     ... we haven't looked at the different important
>     characteristics
>     ... nothing has moved during IETF
>     ... but we're getting back on track now
>
>     dom: getting this list of differences would also help the rest
>     of us know which proposal we are likely to prefer :)
>     ... unless it is sufficient to make you guys decide to merge
>     into one proposal
>
>     justin: @@@
>     ... the other change relates to what happens when you call
>     addStream
>     ... does the local description change right away? or do you
>     have install it with setLocalDescription?
>     ... implicit update seemed like an easy win
>     ... but I need to look at what happens if the state machine is
>     not in the right state when receiving an offer
>     ... Once we resolve this, we could have a draft of a merged
>     proposal
>
>     Cullen: my proposal lets you change the SDP when you add a
>     stream
>     ... e.G. to remove a codec
>     ... this seems an important feature that people wants
>
>     Justin: you could always replace the SDP and
>     setLocalDescription with an updated SDP
>
>     hta: there is also a difference in terms of initiative
>     ... in Adam's proposal, the application just reacts to what the
>     browser does
>     ... in the other proposal, you're on your own to manage the
>     whole ice state machine
>
>     Adam: the browser doesn't really do anything if the developer
>     doesn't do anything
>
>     hta: in the JSEP API, if the application developer decides that
>     he has created a PeerConnection and connected two media streams
>     to it, and want to wait for a while until a specific event
>     ... in the JSEP proposal, you can just not call createOffer()
>     ... in the other proposal, there will be an onsignaling
>     callback — what should you do about it?
>
>     stefanh: the application could still wait to call the addStream
>
>     adam: addStream is still in the control of the JavaScript
>
>     hta: the difference in philosophy is that in one case you get
>     callbacks and you respond to that, in the other you have to
>     manage this on your own
>
>     justin: there were comments that getting callbacks at random
>     times create weird bugs
>
>     stefanh: I want to ensure that cullen, adam and justin have
>     this meeting next Monday
>     ... that meeting should either produce a list of differences,
>     or a merged proposal in a reasonable amount of time
>
>     justin: I think we've enumarated the main differences of the
>     two APIs
>
>     adam: in the browser, everything is asynchronous
>
>     cullen: so our meeting will help the discussions; but I suspect
>     we'll still be back to multiple orthogonal decisions
>     ... I wouldn't be surprised that we will need another phone
>     call to go through this
>
>     stefanh: yes; that would be a better informed phone call though
>
>     adam: clearly the first step is for the 3 of us to better
>     understand the two proposals
>
>     Randell: I'll bring the Data API on the list
>
>     stefanh: and implementation feedback would be very welcome as
>     well
>
> Summary of Action Items
>
>     [NEW] ACTION: anant to move MediaStream spec to getUserMedia
>     [recorded in
>     [30]http://www.w3.org/2012/04/10-webrtc-minutes.html#action01]
>     [NEW] ACTION: burnett to send an updated Capabilities proposal
>     to Media Capture Task Force [recorded in
>     [31]http://www.w3.org/2012/04/10-webrtc-minutes.html#action03]
>     [NEW] ACTION: Dan to send an updated Capabilities proposal to
>     Media Capture Task Force [recorded in
>     [32]http://www.w3.org/2012/04/10-webrtc-minutes.html#action02]
>
>     [End of minutes]
>
>
>
>
Received on Wednesday, 11 April 2012 07:55:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 11 April 2012 07:55:46 GMT