See also: IRC log
<trackbot> Date: 26 May 2015
<adambe> yes
<scribe> Scribe: Dom
Stefan: any request for change to the agenda?
[none]
<dom_scribe> Proposed responses to last call comments
<jib> me
HTA: I propose that we start by
checking whether we are in agreement or not, and file for later
things on which there isn't agreement
... on this particular item, I suggest we mark it as something
we might look at a later time, but "not now"
[no disagreement expressed]
HTA: proposed same response: could think about it, but not yet
[no disagreement expressed]
HTA: we discussed this, and we will document it
AdamB: we've prepared a PR for this, and AnneVK +1'd it
JIB: there is ongoing discussion of data channel in workers though
hta: that's a different spec
<mt> oh, so we're really going through this one by one by one
HTA: I have a question about how
an interfance that is exposed in a worker but references an
interface that isn't, how does that work
... but that's for WebRTC
Stefan: my proposed response is
that we haven't seen use cases that mandate muxed track, and
the current set of APIs should be able to deal with that
... proposed no change in response to the comment
[no disagreement expressed]
HTA: this is a difficult
issue
... one reason being that the labels we pick up come from
systems, we can't translate them on the fly
... I think we need to ask advice from I18N
... we will otherwise assume the language attribute comes from
navigator.language
... I don't think it's settled yet; we need advice from I18N
experts
@@@: I agree given how different labels we get from devices
Stefan: so this requires more work
DanB: where we use capabilities,
we don't have the definitions since they are in the IANA
registry
... assuming we keep the current structure of the document, my
suggestion is to add text with link to the IANA registry
... and then, since the specific properties are defined the
same doc, we will also add informative references to these
Stefan: maybe this needs to be parked until we look at the IANA registry topic
Stefan: Peter looked at
this
... but he's not on the call; HTA, you've been involved too
HTA: my impression from the list is that this is a reasonable thing to do and that we should do this and no more
Shijun: what should be the behavior if the latency is set to a very low value close to zero?
hta: for the constraint or the state?
shijun: the constraint
hta: if you set the max of the constraint to a very low value and it is not satisfiable, then the constraint will fail
shijun: is this audio only? or does it apply to video as well?
hta: I suspect we could have it
for both
... they would probably be different between audio and
video
shijun: should we have some guidance in the spec on dealing with ridiculously low values?
DanB: the behavior for extreme values is the same for all constraints
shijun: ok, that's right
jib: would it be useful to add an example?
stefan: we have a proposal to add
a constraint
... but there seems to be a need for more work
DanB: including on the video piece
Stefan: so consensus to adopt that constraint, but more work is needed?
DanB: "more work" is not sufficient for a LC resolution :)
Shijun: in Microsoft, we will
want to give as low a latency as possible in general
... this max latency is probably not as useful
... at the platform level, we're doing our best to not add any
delay
... this may be useful in other platforms, but I would like to
hear from other implementors on how common that is
HTA: the original request came from someone dealing with a trade off between battery life and latency
shijun: is that from an app developer or a device dev?
HTA: he works for google in speech recognition
DanB: I come from that background
too, and there are a number of cases where low latency is also
critical in this space
... in any case, this is a valuable constraint for speech
recognition
... for a distributed band, this is also critically
important
HTA: on Android, we currently have two paths in the audio subsystem with different latency characteristics, used for different purposes
DanB: re speech recognition, if there is too long of a delay in responses, users tend to react with spectactularly bad behavior
JIB: I understand the original request to enable "OK Google" with low battery consumption
Stefan: OK, this needs more work
hta: there is consensus on adding the constraint, but more work needed on example and explanation
https://github.com/w3c/mediacapture-main/pull/169
Stefan: the change has been made
AdamB: we require the "track"
property now
... using the new WebIDL "required" keyword
... which then enables non-optional dictionaries
[no disagreement expressed]
Stefan: the gUM LC doc defined
the integration in HTML Media Element with srcObject
... but that is now defined in HTML5.1
... we have a pull request that refers to HTML5.1 instead of
defining it on our own
... there is still some unclear pieces in HTML5.1 about
assigning id/kind/label, so we have kept that in our document
for now
DanB: fine with that — only need to fix the title of the spec in the response
[no disagreement expressed]
DanB: this is still under
discussion (not clear yet whether it is difficult)
... good discussion is happening; jib and domenic had a good
back and forth
... which led to a proposal I sent to the list
... we don't have a resolution yet, but it's in progress
hta: another tricky
question
... I tried to look at how Ecmascript deals with
internationalizing errors, but couldn't find any clue
... we should probably clarify that the message property is
used for debugging, not to display to users
... if there is a need for I18N, it should be dealt with at the
Ecmascript level
... suggest no change
JIB: I agree
DanB: clearly this needs to be solved at a different level than ours; it would be confusing for us to try and solve this
Toipc: LC3025 onaddtrack
JIB: I've always interpreted onaddtrack and onremovetrack as "onremoteaddtrack" and "onremoteremotetrack", is that correct?
adambe: it would be more
"onunexpectedaddtrack" and "onunexpectedremovetrack"
... any track event generated by the UA would fit this, not
just remote
hta: e.g. if you produce a stream from a video track, and you change the stream, it might come with a different number of tracks
adambe: I think the track would
end there
... but if someone is sending you a track and add it to a
stream, this should notify the stream of a new track
JIB: isn't the problem that this underspecified at the moment?
hta: the spec doesn't specify
under which conditions the addtrack event fires
... media stream from video might be one such spec
adambe: should we set guidance on
how specs should determine when the addtrack event fire?
... anyway, right now, the main case is remote addtrack
(?)
... I don't think we should notify local track changes
hta: so we adopt the decision of not firing on local track changes, but we need to write up guidance for other specs
adambe: should we add some text in the spec explaining that no feature in gUM will trigger these events, but that other specs will define that
hta: we should do that
danb: so we're making a change
adambe: should we reference webrtc 1.0 as an example?
hta: yes
DanB: we need an updated proposal for that one
stefan: agree
HTA: I saw no compelling reason for change; so suggest no change
[no disagreement expresseð]
Stefan: no proposal yet
HTA: currently under
discussion
... it goes to the broader question of how much information to
make available and when
... The requester agreed on mail that if he had all information
on the device available in enumerateDevices(), his use cases
would be satisified
... but brings a lot of fingerprinting surface
Shinjun: we don't have a complete proposal; it is an interesting topic
DanB: we have discussed this before quite extensively
<mt> https://github.com/w3ctag/spec-reviews/blob/master/2015/05/fingerprint.md
DanB: before we make the decision to reinvestigate this, I would like to see what new information justify reevaluating it
hta: if we want to keep away from "drive-by" web, we need a permission gate
mt: note that the TAG recent finding is interesting input on that aspect
shijun: this is more about audio output rather than input devices, right?
hta: right
shijun: one way to do that is to have some extension point in the future where that can be extended
dom: the TAG statement on fingerprinting and the audio device output api are sufficient information for me
DanB: my proposal is that no new information was provided to justify reopening
martin: note that I never was involved in these discussions
DanB: my intention was to say
that this is a new request, and there doesn't seem to be new
information
... so I don't feel this is like we should re-discuss it; I
don't feel it is a last call comment per se
Martin: there is a lot of changes
in the way W3C has approached its specifications maintenances
in the past 2 years with emphasis on living document and other
aspects of this
... I don't know if these have been considered
hta: they have been considered, but it is far from clear that the W3C has moved to a living document working model
martin: that's true; there doesn't seem to be a single W3C working model
jib: now might be a good time to assess whether the "registration" feature is something anyone will use
hta: are you suggesting we should
treat extensibility as a feature and review it when going to
CR?
... see if anybody uses it?
martin: I like this
dom: FWIW, my recollection of the
consensus was that we didn't have enough experience with
extensibility to settle on a specific mechanism
... but that consensus didn't seem to have taken root in the
spec
danb: I defer to the chairs to
assess whether there was enough consensus or not on the
registry; interesting idea of looking at it as a feature
... just removing it is not enough though
stefan: there was some agreement to look at it as a feature
danb: for features that you might
have trouble getting implementation of, you mark it as "at
risk" in CR
... removing delay to go to PR if you remove it
dom: note that delay is less important in the new process
danb: still, this would create an additional CR round
dom: not sure we need this for this spec since this is procedural
danb: you need this for conformance statement
martin: but does conformance to a moving target — does that make sense?
hta: a conformance statement would say I recognize these values
martin: but that's just conformance to the spec
danb: that question would similarly applies to any IETF spec applying the same procedure
martin: I think that procedure makes sense in some contexts; I don't think it makes sense here, in this implementation context
danb: others have made that
comparison, so I wanted to voice it
... but I don't think we should have that discussion here and
now
... clearly, this needs more discussion
stefan: agreed
<dom_scribe> PR 168
AdamB: there was a confusion
between the concept of active/inactive, and the attribute
... the piece of text with that error is actually not needed at
all
... the active state in a mediastream depends on its tracks
[no disagreement expressed]
<dom_scribe> PR 167
AdamB: the problem there was that
we referred to a algorithms as defined in the public API, e.g.
for clone a stream
... the problem of doing so is that if someone overwrite the
track clone method, we don't want that changed behavior to be
reflected in the mediastream
... so we need to use private algorithms that are referenced by
the public API and other points where needed
[no disagreement expressed]
AdamB: we had 2 concepts for
stopping a track
... "stopping" and "detaching" a track source
... this was unnecessarily complicated, and it was suggested we
should use just one
... sounds like the right thing to do
[no disagreement expressed]
DanB: this is linked the
constrainable pattern template
... WebIDL doesn't allow us to express this
... this creates failure if you try to check the document in
the webidl checker
... my proposal is to describe in a little more details these
limitations
... it's worth noting that MediaStreamError will be also result
in non-WebIDL complete definitions
... we'll need ES6 style language, and thus there will no IDL
for them
Dom: is there any spec that is going to re-use ConstrainablePattern?
AdamB: MediaRecorder I think?
Stefan: Image Capture too I think, not sure
[no disagreement expressed]
JIB: there were specific complaints about capabilities and settings; we could use a quick fix with empty dictionaries as we did for constraints
hta: that's a work around we could choose to apply or not
danb: I'm not rejecting that; let's talk about a little bit
HTA: I'll send my summary of our decisions
Shijun: I had a comment on the
latency constraint
... I wonder if it would be better to define it as a boolean
value rather than a double
... the latency might be dynamic depending on the system
load
... if the purpose is power-saving, lower resolution values
might be better
hta: this was discussed on the
list
... the conclusion was that there are so many different use
cases that using boolean to separate this was probably
unwise
shijun: I didn't notice that in the mailing list
hta: there is a question about
whether the latency is operational or a guarantee
... it's hard to guarantee a latency due to system load as you
mention
... that's worth discussing more on the list
danb: "how fuzzy are the values allowed to be"
shijun: also the distinction between initial static latency and running latency
hta: I suspect many implementations will use a threshold to determine which codepath to use
shijun: testing will be headache; you'll have to trust the platform
hta: the chairs will take on
processing the ones we think we have resolved and pass them on
to the proposers and see if they're happy
... thanks all for coming
trackbot, end meeting