Web Real-Time Communications Working Group Teleconference

10 Apr 2012


See also: IRC log


+1.403.244.aaaa, Dan_Burnett, Cullen_Jennings, Jim_Barnett, +1.415.800.aabb, dom, +, stefanh, +, adambe, +1.908.541.aaee, +1.650.961.aaff, +1.415.800.aagg, anant, derf, Dan_Druta, +1.610.889.aahh, Jérôme Marcon, jesup, +47.41.44.aajj, hta, nstratford, +1.617.575.aakk, juberti, +1.408.902.aall, +1.650.678.aamm, Narm_Gadiraju
Stefan_Hakansson, Harald_Alvestrand
juberti, dom


<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> March 13 minutes

stefan: first action - approve minutes from last meeting

hta: if no objections, they are approved

<dom> jesup, http://lists.w3.org/Archives/Public/public-webrtc/2012Mar/0072.html

<dom> Open Action items

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> 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: http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html Constraints and Capabilities API for getUserMedia

<trackbot> ACTION-11 Add Constraints API to API spec notes added

<dom> ACTION-13: http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0033.html Constraints and Capabilities API for getUserMedia

<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> 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> http://www.w3.org/2011/04/webrtc/track/actions/18

<dom> Any overlap with webrtc WG?, Stefan Hakansson LK on March 20

stefan: don't think there are they many similarities, Stefan will follow up and see if there is any overlap

<dom> ACTION-18: see 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> 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 http://dev.w3.org/2011/webrtc/editor/webrtc.html#peerconnection to strings

<dom> Doodle for picking dates for next RTCWeb meeting

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 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> Audio WG request for feedback

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

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 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 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].


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 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 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 http://www.w3.org/2012/04/10-webrtc-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/04/11 09:00:40 $