[minutes] May 26 teleconf

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