- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 11 Apr 2012 09:55:13 +0200
- 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 UTC