- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 11 Apr 2012 09:01:18 +0200
- To: public-webrtc@w3.org
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: @@@
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:01:45 UTC