- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 26 May 2015 18:25:50 +0200
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Hi,
The minutes of the teleconference held today on last call comment
processing are available at:
http://www.w3.org/2015/05/26-mediacap-minutes.html and pasted as text below.
Please send corrections to the list.
Dom
Media Capture Task Force Teleconference
26 May 2015
See also: [2]IRC log
[2] http://www.w3.org/2015/05/26-mediacap-irc
Attendees
Present
Dan_Burnett, StefanH, HTA, Dom, Giri, Shijun,
Adam_Roach, AdamB, Jan-Ivar, Martin
Regrets
Chair
stefanh, hta
Scribe
Dom
Contents
* [3]Topics
1. [4]Agenda bashing
2. [5]Walk-through proposed responses
3. [6]LC3013 related streams such as captions or
subtitles
4. [7]LC3009 asking about defining a video filter chain
5. [8]LC3018 please use [Exposed]
6. [9]LC3020 asking for video+audio (muxed) as a new
track type
7. [10]LC3026 internationalization of device “label”
8. [11]LC3021 capabilities registration
9. [12]LC3022 latency constraint
10. [13]LC3015 TrackEvent not nullable
11. [14]LC3016 Direct assignment to media elements
12. [15]LC3017 MediaStreamError
13. [16]LC3027 Internationalization of “message”
14. [17]LC3010 enumerateDevices() should be getAll()
15. [18]LC3023 More information about devices available
before using getUserMedia
16. [19]LC3024 Removing the constraint registry
17. [20]LC3012 Active attribute description
18. [21]LC3011 addTrack() description is not tamper free
19. [22]LC3014 Life cycle and media flow (remove
“detached”)
20. [23]LC3019 IDL errors
21. [24]Conclusions
* [25]Summary of Action Items
__________________________________________________________
<trackbot> Date: 26 May 2015
<adambe> yes
Agenda bashing
<scribe> Scribe: Dom
Stefan: any request for change to the agenda?
[none]
Walk-through proposed responses
<dom_scribe> [26]Proposed responses to last call comments
[26]
https://lists.w3.org/Archives/Public/public-media-capture/2015May/att-0075/DispositionofComments-LC1forMediaCaptureandStreams.pdf
<jib> me
LC3013 related streams such as captions or subtitles
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]
LC3009 asking about defining a video filter chain
HTA: proposed same response: could think about it, but not yet
[no disagreement expressed]
LC3018 please use [Exposed]
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
LC3020 asking for video+audio (muxed) as a new track type
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]
LC3026 internationalization of device “label”
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
LC3021 capabilities registration
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
LC3022 latency constraint
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
LC3015 TrackEvent not nullable
[27]https://github.com/w3c/mediacapture-main/pull/169
[27] 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]
LC3016 Direct assignment to media elements
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]
LC3017 MediaStreamError
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
LC3027 Internationalization of “message”
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
LC3010 enumerateDevices() should be getAll()
HTA: I saw no compelling reason for change; so suggest no
change
[no disagreement expresseð]
LC3023 More information about devices available before using
getUserMedia
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>
[28]https://github.com/w3ctag/spec-reviews/blob/master/2015/05/
fingerprint.md
[28]
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
LC3024 Removing the constraint registry
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
LC3012 Active attribute description
<dom_scribe> [29]PR 168
[29] https://github.com/w3c/mediacapture-main/pull/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]
LC3011 addTrack() description is not tamper free
<dom_scribe> [30]PR 167
[30] https://github.com/w3c/mediacapture-main/pull/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]
LC3014 Life cycle and media flow (remove “detached”)
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]
LC3019 IDL errors
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
Conclusions
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
Received on Tuesday, 26 May 2015 16:25:54 UTC