See also: IRC log
<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?
<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
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
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
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)
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
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