IRC log of webrtc on 2020-10-20
Timestamps are in UTC.
- 14:51:38 [RRSAgent]
- RRSAgent has joined #webrtc
- 14:51:38 [RRSAgent]
- logging to https://www.w3.org/2020/10/20-webrtc-irc
- 14:51:40 [Zakim]
- Zakim has joined #webrtc
- 14:56:29 [JoachimReiersen]
- JoachimReiersen has joined #webrtc
- 14:58:42 [TimPanton]
- TimPanton has joined #webrtc
- 15:00:41 [dom]
- Meeting: W3C WebRTC Virtual TPAC Meeting #1
- 15:01:41 [chanelhuang]
- chanelhuang has joined #webrtc
- 15:02:07 [dom]
- Present+ Dom, DrAlex, Bernard_Aboba, Eero_Hakkinen, Elad_Alon, Florent_Castelli, Guido_Urdaneta, Harald_Alvestrand, Henrik_Bostrom, Jan-Ivar, Joachim_Reiersen, Palak_Agarwal, Cullen_Jennings, Tim_Panton, Xinhong_Yuan
- 15:02:17 [dom]
- Present+ Chanel_Huang
- 15:02:33 [eehakkin]
- eehakkin has joined #webrtc
- 15:02:34 [dom]
- Bernard: focus is to make progress on our specs, incl getting some of our specs to CR & PR
- 15:03:06 [dom]
- Agenda: https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/
- 15:03:10 [dom]
- -> https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/ Slides
- 15:03:23 [dom]
- Bernard: Today, we'll work largely on existing specs and Thursday, new work
- 15:03:30 [dom]
- Present+ Chunbo_Hua
- 15:03:53 [dom]
- Present+ Shachar_Zohar, Carine_Bournez, Eric_Carlson, Rijubrata_Bhaumik
- 15:03:57 [dom]
- Topic: WG Status
- 15:04:05 [dom]
- harald: We've been rechartered to continue to do what we were doing
- 15:04:09 [dom]
- ... finish WebRTC 1.0
- 15:04:21 [dom]
- ... describe requirements from new use cases and address them
- 15:04:22 [vr000m]
- Can someone let me in to the google meet?
- 15:04:39 [dom]
- ... WebRTC 1.0 should just work across browsers, networks
- 15:05:03 [dom]
- ... we should have low level data access with high perf- think of funny hats, voice compression, background blur
- 15:05:12 [dom]
- ... We're not getting as much demand for ORTC and sons
- 15:05:21 [dom]
- ... WebTransport and WebCodecs are basically where that action has moved
- 15:05:30 [dom]
- ... Insertable streams will also help on that side
- 15:05:51 [dom]
- ... once you can get the information of what's going on up and down the JS API, that should help do what ORTC was set out to do
- 15:05:59 [dom]
- ... In terms of document status
- 15:06:15 [dom]
- ... Media Capture and Streams is a CR, with a few open issues (incl old ones)
- 15:06:31 [dom]
- ... not much has changed, but some new ideas for the in-borwser device picket to deprecate the constraints-picker based mechanism
- 15:06:44 [dom]
- ... but overall, this is working as intended, with lots of products depending on it
- 15:06:48 [dom]
- Present+ Daniel_Burnett
- 15:07:17 [dom]
- ... we're trying to push new things to extensions as we can, possibly with some back merge using the process 2020 capabilities to merge new features
- 15:07:20 [dom]
- ... plans is to target Rec by Q1 2020
- 15:07:24 [dom]
- s/2020/2021
- 15:07:35 [dom]
- ... next: screen capture
- 15:07:44 [dom]
- Present+ Jozsef_Vass
- 15:07:54 [dom]
- ... a key feature in our increasinly virtual environment
- 15:08:04 [dom]
- ... we need to go through TAG review
- 15:08:12 [dom]
- ... a new proposal emerged on tab sharing
- 15:08:17 [dom]
- Present+ Peng_Liu
- 15:08:37 [dom]
- ... Next spec: WebRTC 1.0, published as final CR (famous last words)
- 15:08:47 [peng_]
- peng_ has joined #webrtc
- 15:08:53 [dom]
- ... 10 open issues, mostly editorial, one privacy; most should be easy to fix once we get around to it
- 15:09:04 [dom]
- ... the implementation maps show good progress on interop
- 15:09:19 [dom]
- ... the community sense is that it's being used in billions of hours per day
- 15:09:27 [dom]
- ... we promised a Rec in Q4 2020 (now)
- 15:09:40 [dom]
- ... Next: WebRTC Identity - nothing has happened on it
- 15:09:53 [dom]
- ... it's still referenced from WebRTC, but we will ask forgiveness for it
- 15:10:09 [dom]
- ... In terms of Resources Availables - only 2 non-chairs editors (Henrik and Youenn)
- 15:10:19 [dom]
- ... pull requests coming from them and Jan-Ivar for the most part
- 15:10:26 [dom]
- ... other contributes PRs - thank to you
- 15:10:33 [dom]
- ... we need more workforce as editors
- 15:10:47 [dom]
- Present+ Varun_Singh
- 15:11:00 [dom]
- HTA: we can't force anyone to work, but please volunteer if you want stuff to happen
- 15:11:17 [dom]
- ... Other active documents: capture from DOM is heavily used, no recent big changes, need to go through wide review and close open issues
- 15:11:38 [dom]
- ... Likewise, Recorder needs updates - we're missing an editor
- 15:11:53 [dom]
- ... Stats Identifiers is getting active edits, and the issues are under control
- 15:12:34 [dom]
- ... Other documents are more quiet: depth, audio output devices, content hints, priority
- 15:12:50 [dom]
- ... In terms of other activity in W3C: WebCodec, WebTransport (happening in WGs)
- 15:13:21 [dom]
- ... we had a joint meeting with the Media Interest Group which showed interest across the community - no specific proposal emerged out of it though
- 15:13:45 [dom]
- ... lots of people caring deeply about security and privacy issues and want to make sure we write specs that respect security & privacy
- 15:14:07 [dom]
- ... In this meeting, we want to finish 1.0 - we're close to get them shipped, which will allow us to look at new APIs
- 15:14:21 [dom]
- ... the use cases and requirements are key; raw media is kind of the current burning issue for lots of people
- 15:14:24 [eric_carlson_]
- eric_carlson_ has joined #webrtc
- 15:14:42 [dom]
- ... we've taken up a couple of proposals to access raw media and deal with it, which we will discuss on Thursday
- 15:15:11 [dom]
- ... any question before we dive in testing?
- 15:15:19 [dom]
- Topic: Testing and implementation status
- 15:16:38 [dom]
- DrAlex: this is an update to the presentation from last year, will cover the slides fast
- 15:17:06 [dom]
- ... It remains difficult to compute the coverage of the spec in terms of testing
- 15:17:28 [dom]
- ... our spec is instrumented to keep track of which parts of the spec is covered
- 15:17:39 [dom]
- Bernard: also, it only focuses on W3C specs, not the IETF specs
- 15:18:00 [dom]
- DrAlex: correct - particularly relevant when it comes to network testing or simulcast
- 15:18:19 [burn]
- burn has joined #webrtc
- 15:18:28 [dom]
- ... If you look at the tests we do have in Web Platform Tests - the number of tests has risen, and the number of passes have increased too
- 15:18:46 [dom]
- ... slow progress since last year though
- 15:19:06 [dom]
- ... we have heard frustration from non-browser vendors in getting their tests merged in WPT
- 15:19:35 [dom]
- ... we need to decide how to rekindle that process, and make sure contributions are indeed processed
- 15:19:57 [dom]
- ... [showing results from running Web Platform Tests in Kite]
- 15:22:06 [dom]
- ... Kite shows 66% pass; Kite can take a more granular approach to counting results than what WPT does by default (one failure per test, not per test file)
- 15:22:19 [dom]
- ... we've gone from 66% to 70.6% in 2020
- 15:22:33 [dom]
- ... improvements across all browsers
- 15:22:55 [dom]
- ... In terms of Simulcast & SVC: WPT can't test peer-to-peer usage, you need network instrumentation to test ICE
- 15:23:23 [dom]
- ... that became a bigger problem in 2015 when simulcast was added to 1.0
- 15:23:38 [dom]
- ... the simulcast loopback by Philip Hancke helped with getting simulcast visibility in WPT
- 15:24:03 [dom]
- ... after several hackathons and sprints on this, I think we're pretty good now
- 15:24:25 [dom]
- Aboba: the loopback test has helped identify pretty big protocol bugs (e.g. missing MIDs in FF)
- 15:24:45 [dom]
- DrAlex: right - my fear is that there may be more big bugs hiding behind what WPT can actually test
- 15:25:09 [dom]
- ... we've been able to run reports on WebRTC support across various SFU
- 15:25:22 [dom]
- ... we had a good experience testing browsers with SFU during an IETF hackathon
- 15:25:37 [dom]
- ... but this is a lot of work that has proved difficult to reproduce esp with IETF going virtual
- 15:26:08 [dom]
- Bernard: when might we go back to this?
- 15:26:11 [TimPanton]
- q+
- 15:26:29 [dom]
- DrAlex: hard to tell - SFU vendors aren't W3C members, more focused on protocols than JS
- 15:27:08 [dom]
- ... one of the limitations of testing simulcast via SFU is that it depends on specific approaches from the various vendors
- 15:27:18 [dom]
- ... even finishing basic tests have proved difficult to get done
- 15:27:46 [riju]
- riju has joined #webrtc
- 15:27:49 [dom]
- Tim: I can offer to help talk with SFU vendors if we have a concrete proposal
- 15:28:03 [dom]
- ... there was a proposal to have vancouver hackathon that was overtaken by events
- 15:28:20 [dom]
- ... hopeful we'll get one in November
- 15:28:56 [dom]
- DrAlex: I thought the Vancouver proposal was specifically targeted for non-JS environments
- 15:29:16 [dom]
- Tim: there are lots of people interested in having simulcast work, and SFUs have moved on a lot, with much more public APIs
- 15:29:28 [dom]
- ... I think it's worth going back to that group with a concrete proposal
- 15:30:16 [dom]
- DrAlex: let's do this then
- 15:30:21 [eehakkin]
- Present+ Eero_Häkkinen
- 15:30:25 [dom]
- Tim: I'm happy to take the action if there is a clear ask
- 15:30:29 [dom]
- RRSAgent, draft minutes
- 15:30:29 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/10/20-webrtc-minutes.html dom
- 15:30:37 [dom]
- RRSAgent, make minutes public
- 15:30:37 [RRSAgent]
- I'm logging. I don't understand 'make minutes public', dom. Try /msg RRSAgent help
- 15:30:45 [TimPanton]
- q-
- 15:30:45 [dom]
- RRSAgent, make log public
- 15:31:23 [dom]
- Carine: the WG is now under the new W3C process 2020
- 15:31:32 [dom]
- ... a few differences in it for Proposed Rec
- 15:32:09 [dom]
- ... the first few criteria are unchanged: two interoperable impl of each features, wide review (already done), close issues that we received during CR, do not make substantive changes
- 15:32:18 [dom]
- ... (CRs are now either Snapshots or Drafts)
- 15:32:45 [dom]
- ... no substantive changes can be made to the last CR Snapshot when going to Proposed Rec (as they would invalidate the patent policy commitments)
- 15:32:52 [dom]
- ... we can remove features marked at risk in the previous CR
- 15:33:19 [dom]
- ... for WebRTC 1.0, no change has been since our last CR snapshot and we have one feature marked at risk
- 15:33:58 [dom]
- ... 10 open issues on webrtc-pc, 4 editorials, 7 ready for pull requests, 4 questions or test suites issues - nothing substantive that would prevent us to go to Proposed Rec
- 15:34:21 [dom]
- ... only received 4 issues in the last month, 2 editorials; there may be open questions on whether other testing issues may emerge (e.g. on simulcast)
- 15:34:59 [dom]
- ... WPT has shown improvements; we've developed an interoperability report showing what has no implementation or only 1 implementation
- 15:35:08 [dom]
- ... (considering Chrome and Edge as a single implementation)
- 15:35:28 [dom]
- ... the major pieces that have only 1 implementation are SCTPTransport, IceTransport, setStreams, DataChannel.onclosing
- 15:35:43 [dom]
- ... to go to PR, we need to document the situation on simulcast for the transition request
- 15:36:10 [dom]
- ... previously we were also tracking progress on IDL interface implementations - that report now is mostly equivalent to what we get from WPT
- 15:36:32 [dom]
- ... the table remains interesting as it maps gaps to specific APIs pieces
- 15:37:08 [dom]
- ... since last year, more green, less orange and red - shows improvements overall
- 15:37:52 [dom]
- ... for consideration to the WG: we have 2 main features without double implementations IceTransport and SctpTransport (setStreams and onclosing are expected to be implemented reasonably shortly)
- 15:38:03 [dom]
- ... the 2 transports will be implemented but in a slower timescale
- 15:38:31 [dom]
- ... Process 2020 allows to fix recommendations post-facto if bugs emerge, so our feeling is that we should recommend Proposed Rec with the current state of implementations
- 15:38:44 [tuukkat_]
- tuukkat_ has joined #webrtc
- 15:38:46 [dom]
- ... knowing that IceTransport and DtlsTransport would be part of the spec, are going to be implemented
- 15:39:03 [dom]
- ... if we discover bugs as these implementation emerge, we would be able to get the Rec updated to fix it
- 15:39:34 [dom]
- ... so we're suggesting not to delay WebRTC 1.0 any further and ask the Director to approve that situation
- 15:40:09 [dom]
- Bernard: we've been talking about the testing problem for a while; WPT limitations have been underlined recently with a breakage in mux/demux code
- 15:40:22 [dom]
- ... not covered in WPT, more of an IETF functionality
- 15:40:35 [dom]
- ... WPT is used both for W3C processes, but also for regression testing in browsers
- 15:40:49 [dom]
- ... Kite can't be run for regression testing
- 15:40:55 [fluffy_]
- fluffy_ has joined #webrtc
- 15:41:33 [dom]
- HTA: on that specific bug, once we understood what it was, we were able to produce a WPT test for it
- 15:41:47 [dom]
- Bernard: how was that managed?
- 15:41:56 [dom]
- HTA: Fippo mangled the SDP in a smart way
- 15:44:15 [dom]
- Dom: WPT is an open source project - maybe worth bringing this to the community and see if there is interest in stronger instrumentation for network
- 15:44:38 [dom]
- Alex: we proposed to bring WPT.fyi results based on Kite, but haven't heard back
- 15:44:56 [dom]
- Aboba: we have similar issues in WebTransport - we've written little servers that run in WPT
- 15:47:49 [dom]
- Alex: we could do that for simulcast, but we didn't get any reaction on our simpler proposal, so not holding my breath
- 15:48:11 [dom]
- Dom: still worth investigating in my opinion if we think the ecosystem would derive significant value
- 15:48:16 [dom]
- Topic: WebRTC Stats
- 15:48:37 [dom]
- Henrik: updates from last TPAC - we had lots of discussions around enabling simulcast which required moving lots of stats around
- 15:49:27 [dom]
- ... That migration has now been completed
- 15:49:39 [dom]
- ... outbound-rtp objects are generated per simulcasts layers
- 15:49:49 [dom]
- ... track stats have been made obsolete as they can be found elsewhere
- 15:50:11 [dom]
- ... in Chromium, M86 shows that migration completed
- 15:50:25 [dom]
- ... we keep track stats for backwards compat (with the old design)
- 15:51:10 [dom]
- ... the stats now map pretty closely with the object model of the WebRTC API
- 15:52:25 [dom]
- ... only a subset of the new stats types have been implemented - missing remote-outbound-rtp, sender, receiver, transceiver, sctp transport metrics, ice server metrics, csrc (but that's already available in get{Synchronization,Contributing}Sources
- 15:53:35 [dom]
- ... all in all, most things are available but there are some things missing, some are available outside of getStats, some aren't
- 15:54:25 [dom]
- ... In terms of Mandatory stats, we have 66 out of 77 implemented in Chromium M87; FF and Safari have lots of impl, but also many gaps
- 15:54:40 [dom]
- ... over 170 metrics have been implemented, not sure what percentage that represents
- 15:55:01 [dom]
- ... Beyond moving stuff around, not a lot of activity on spec / implementations
- 15:55:22 [dom]
- ... Does that mean we're all good? I think Stats are in pretty good shape, mostly polishing work needed
- 15:55:41 [dom]
- DrAlex: is simulcast going to work the same with SVC?
- 15:55:50 [dom]
- Henrik: the simulcast stats don't cover SVC
- 15:56:22 [dom]
- ... we discussed SVC stats at last TPAC, but this is blocked on a proper API for SVC?
- 15:56:35 [dom]
- DrAlex: so webrtc-SVC?
- 15:57:06 [dom]
- Varun: we're indeed waiting on the SVC API approval
- 15:57:18 [dom]
- Florent: we wanted to get experience on the SVC spec stuff before writing the stats for it
- 15:57:37 [dom]
- Varun: if things are good enough, how do we move to the next stage?
- 15:59:51 [dom]
- Dom: I think we may want to take advantage of the living standards model from process 2020
- 16:00:20 [dom]
- Shachar: I would like to see more traction on the SCTP transport stats
- 16:00:40 [dom]
- Varun: in terms of implementations right?
- 16:01:18 [dom]
- Henrik: I don't have an update on that - not spending a lot of time on getStats right now, haven't heard lots of demand for it
- 16:01:44 [dom]
- Jan-Ivar: we're committed to implement MTI stats, but not committed to a specific timeline at the moment
- 16:01:59 [dom]
- ... sctp transport stats can be shimmed from what I can remember
- 16:02:14 [dom]
- Varun: we've added a couple of metrics from the low level stack (e.g. RTT)
- 16:02:22 [dom]
- Jan-ivar: but they're not mandatory, right?
- 16:02:29 [dom]
- Henrik: correct
- 16:03:09 [dom]
- Varun: we had a privacy review recently which led to removing networkType
- 16:04:43 [dom]
- Topic: Media Capture and Streams
- 16:05:57 [dom]
- Jan-Ivar: we had a joint meeting with PING (privacy Interest Group) last week
- 16:06:16 [dom]
- ... on the 12 issues they had filed, 4 are still open and 8 were closed
- 16:06:35 [dom]
- ... I propose to review the issues we presented with the solutions
- 16:06:59 [dom]
- ... #640 on revealing label of devices in a more limited way
- 16:07:28 [dom]
- ... we've suggested we can't solve this in the short term for web compat; in the longer term, the in-browser device picker is where we see the solution, being developed in mediacapture-extensions
- 16:08:14 [dom]
- ... we were encouraged to clarify sanitization and the purposes of the labels as being for display only
- 16:08:29 [dom]
- ... on #645, limit enumerateDevices to the type of devices being shared
- 16:08:43 [dom]
- ... we will align with what Chromium implements which is more privacy sensitive
- 16:09:16 [dom]
- ... on #646, we learned that returning empty lists is not web compatible, so won't do this but give clarifications on waht UAs are allowed to do for privacy mitgiations
- 16:10:01 [dom]
- ... #672 getCapabilities privacy - already limited to be usable only during capture; feature at risk, may be revisited later in browser picker
- 16:10:21 [dom]
- ... Beyond privacy issues, looking at regular issues
- 16:10:56 [dom]
- ... #660 handling of rotation for camera capture streams
- 16:11:36 [dom]
- ... current implementations assume that constraints are always in landscape, but getSettings get rotate in portrait mode
- 16:11:59 [dom]
- ... the proposal is to specify this (since that's already what browsers do) and it avoids thorny issues about overconstrainted situations
- 16:12:10 [dom]
- Youenn: +1
- 16:12:19 [dom]
- ... have you tried applyConstraints too?
- 16:12:37 [dom]
- Jan-Ivar: I haven't, but I think we should specify it would work the same
- 16:13:21 [dom]
- ... #735 change fitness distance from MAY to SHOULD
- 16:13:40 [dom]
- ... to help with web compat for device selection, for this spec but also image capture
- 16:15:42 [dom]
- Youenn: MAY vs SHOULD doesn't really change much; I don't think we can do MUST with a better defined algorithm
- 16:15:53 [dom]
- ... PTZ may need more detailed handling
- 16:16:08 [dom]
- ... fitness distance is difficult to use to get the results we want
- 16:16:26 [dom]
- ... I would like to have at least guidelines we agree on, to make that SHOULd stronger
- 16:16:44 [dom]
- ... the additional issue I have with fitness distance in general is that you end up with equal fitness distances across devices
- 16:16:58 [dom]
- ... which may also be the source of interop issues
- 16:17:24 [dom]
- Jan-Ivar: I think MAY is pretty weak, which may be coming from FF having a permission prompt
- 16:17:41 [dom]
- ... that MAY feels more a bug to me
- 16:18:07 [dom]
- ... FF allows the user to override the desires (constraints) from the app, which we can address with a separate MAY
- 16:18:24 [dom]
- HTA: another source of input to picking a device is the one identified as the default one
- 16:18:45 [dom]
- Youenn: the PR looks fine, but there are cases with PTZ where this may not work
- 16:19:19 [dom]
- Henrik: the goal is to clarify our intent that this is what ought to be done
- 16:19:39 [dom]
- Jan-Ivar: not much has happened on mediacapture-extensions for the in-browser picker
- 16:19:48 [dom]
- ... we want to move away from in-content device selection
- 16:19:56 [dom]
- ... we wants privacy-by-default in browser picker
- 16:20:15 [dom]
- ... We've seen progress in audio speaker section with selectAudioOutput() in the last year
- 16:20:36 [dom]
- ... that gets you a picker, which if agreed exposes a deviceId to the app which can uses it for setSinkId
- 16:20:47 [dom]
- ... it also allows to work without mic permission
- 16:20:54 [dom]
- ... Safari drove the design of that improvement
- 16:21:21 [dom]
- ... We also added a deviceId member to selectAudioOutput to help with remembering devices
- 16:21:40 [dom]
- ... (which the UA can still put behind a permission prompt, e.g. to deter trackers)
- 16:22:25 [dom]
- ... This design can serve as inspiration for picking mic/cameras, but that problem is more complex
- 16:22:57 [dom]
- ... you may need several cameras, microphones, apps want to guide camera selection (e.g. resolution)
- 16:23:33 [dom]
- ... more importantly, there is a question on how to migrate from current getUserMedia to that new device picker model which gives less power to developers
- 16:24:16 [dom]
- ... the main privacy issues right now are during capture
- 16:24:57 [dom]
- ... we're thinking of an incremental API; FF already has an in-browser picker
- 16:25:22 [dom]
- ... we would provide a new mode ("semantics") called "browser-chooses" vs "user-chooses"
- 16:26:16 [dom]
- ... with the goal of flipping the default over time - doing that would probably create new permissions prompts
- 16:26:30 [dom]
- ... the end goal is to remove labels
- 16:27:25 [dom]
- Henrik: if you don't flip the default, how could you possibly remove labels?
- 16:27:33 [fluffy]
- q+
- 16:27:52 [dom]
- Jan-Ivar: the first big step is having "user-chooses" in all browsers, at which point all sites can upgrade to user-chooses and skip having an in-content device picker
- 16:28:14 [dom]
- ... the stick is that we would remove labels, which makes the old mode less appelaing
- 16:28:26 [weiler]
- weiler has left #webrtc
- 16:29:04 [dom]
- fluffy: +1 on getting better way of doing this - better control of input devices is greatly needed
- 16:29:19 [dom]
- ... but I don't think the stick is going to work as an approach
- 16:29:34 [dom]
- jan-ivar: the goal is to give motivation for the migration
- 16:29:38 [TimPanton]
- q+
- 16:30:00 [dom]
- ... the migration path may work on a long timescale
- 16:30:19 [dom]
- fluffy: but this needs to be developed with the app vendors
- 16:31:03 [dom]
- jan-ivar: removing the labels is what we need to do to plug the privacy leak
- 16:31:11 [dom]
- ... the API is meant to lessen that pain
- 16:31:51 [dom]
- Youenn: Web app developers will compare the two UX; if the new one is better, that's a pretty good motivation
- 16:32:09 [dom]
- TimP: what happens if you do the two last steps to a site that hasn't been updated in 3 years
- 16:32:28 [dom]
- ... would the right thing just happens in terms of UX?
- 16:32:51 [dom]
- Henrik: the user would get what they want, but the in-app picker would show a stale UI with meaningless labels
- 16:33:14 [dom]
- Youenn: one downside is having both approaches in a given browser is that there will 2 prompts that users will have to understand
- 16:34:05 [dom]
- timp: the devices that get exposed in enumrateDevices may change once the default is flipped
- 16:34:41 [dom]
- Jan-Ivar: there are 2 types of sites: with device management, and without it
- 16:35:04 [dom]
- Henrik: only returning the chrome-selected device as a migration path would break device updates
- 16:36:01 [dom]
- Jan-Ivar: we got positive feedback from PING
- 16:36:17 [dom]
- ... we plan to implement selectAudioOutput and use that as input for the new API
- 16:36:20 [TimPanton]
- q-
- 16:36:33 [dom]
- Fluffy: so you do not plan to deprecate that in the 1.0 timeframe
- 16:36:40 [dom]
- Jan-Ivar: correct - longer term
- 16:37:20 [dom]
- Henrik: the only thing that goes away in 1.0 is that enumerateDevices only returns 1 device per type prior to actual capture
- 16:37:28 [dom]
- Jan-Ivar: correct, stricter than it used to be
- 16:38:50 [dom]
- ... some push back buttons from a couple of app vendors, but the privacy reasoning has been stronger
- 16:38:59 [dom]
- Topic: Screen Capture
- 16:39:06 [dom]
- SubTopic: Issue 60 - Tab Capture
- 16:40:05 [dom]
- Harald: the idea of a tab was not defined; the closest thing seems to be a "browser display surface", which I suggest we refer to this as the correct term
- 16:40:49 [dom]
- Jan-Ivar: terminology-wise, we've used browsing context instead of "current document"
- 16:41:21 [dom]
- Henrik: +1 - I think we have language that says we can't change the source, does that apply here?
- 16:41:37 [dom]
- Jan-Ivar: the source here is the container (the content displayed in it is not the source)
- 16:41:53 [dom]
- ... that's probably what most users would understand too (that capture doesn't end when you hit the back button)
- 16:42:16 [dom]
- Henrik: what about switching tabs?
- 16:42:39 [dom]
- Jan-Ivar: I think of this as a "virtual source" - the point here is to avoid confusing users
- 16:42:50 [dom]
- Henrik: OK, I think that's worth clarifying
- 16:44:08 [dom]
- Guido: wrt sources, it's linked to the deviceId setting (although not exposed to app developers)
- 16:44:26 [dom]
- Jan-Ivar: displayMedia doesn't have a device Id, but it exposes labels
- 16:44:38 [dom]
- ... there is some guidance on UX in the spec given the security risks
- 16:44:54 [dom]
- Youenn: some people are asking to be able to know if a tab is same origin or not, whitelisted or not
- 16:45:04 [dom]
- ... and be able to mute the track if so
- 16:45:35 [dom]
- ... for that, we would need an event that signals the tracks is getting opaque
- 16:46:00 [dom]
- Topic: Image Capture
- 16:46:09 [dom]
- Jan-Ivar: 2 issues with Pan/Tilt/Zoom
- 16:46:46 [dom]
- ... the spec needs a way to call getUserMedia with Pan/Tilt/Zoom, but without specifying a value for Pan (e.g. don't want to move the camera just to ask permission)
- 16:47:03 [dom]
- ... they invented "true" as a placeholder in stead of a value
- 16:47:17 [dom]
- ... but this didn't work correctly with fitness distance
- 16:50:22 [dom]
- Youenn: with PTZ being a privileged feature, we're not sure that fitness distance will be the right approach
- 16:50:30 [dom]
- Jan-Ivar: that's probably covered by the SHOULD
- 16:50:37 [dom]
- ... but the fix still needs to be fixed
- 16:53:10 [dom]
- ... Also unspecified how non-PTZ cameras satisfy default value - e.g. needs Zoom to be adjustable
- 16:54:28 [dom]
- ... two proposals on the able - make values other than 1 for zoom request adjustable zoom; make any value for zoom request adjustable zoom
- 16:57:35 [dom]
- Youenn: PTZ should be restricted to applyConstraints with specific values
- 16:57:43 [dom]
- ... booleans for device selection make sense
- 16:57:50 [riju]
- q+
- 16:58:06 [fluffy]
- q-
- 16:58:08 [dom]
- ack riju
- 16:58:36 [dom]
- riju: any implementation plans for this?
- 16:58:40 [dom]
- jan-ivar: no current plan
- 16:58:49 [dom]
- youenn: no short terms plans, but we welcome patches
- 16:58:52 [dom]
- jan-ivar: likewise
- 16:59:16 [dom]
- henrik: to me it's confusing to mix picking and configuring e.g. for zoom
- 16:59:20 [dom]
- youenn: +1
- 16:59:23 [TimPanton]
- +1
- 16:59:28 [eehakkin]
- q+
- 16:59:37 [dom]
- jan-ivar: the goal here is to align with the constraints syntax
- 16:59:47 [dom]
- ... that's why I'm more for Proposal B
- 16:59:58 [dom]
- ... (i.e. any value for zoom requests adjustable zoom)
- 17:00:33 [dom]
- youenn: if we think boolean values for getUserMedia, specific values for applyConstraints, we should do that in the spec
- 17:00:41 [dom]
- jan-ivar: I think that still implies proposal B
- 17:00:57 [dom]
- Youenn: so the restriction would be discussed as separate issue?
- 17:01:11 [eehakkin]
- q-
- 17:01:18 [dom]
- ... sounds reasonable
- 17:01:44 [dom]
- Topic: Media Capture from DOM
- 17:02:00 [dom]
- ... #24 & #85 to help move media capture from DOM forward
- 17:03:25 [dom]
- Harald: +1 to Jan-Ivar's proposal
- 17:03:38 [dom]
- RRSAgent, draft minutes
- 17:03:38 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/10/20-webrtc-minutes.html dom
- 17:03:40 [dom]
- RRSAgent, draft minutes v2
- 17:03:40 [RRSAgent]
- I have made the request to generate https://www.w3.org/2020/10/20-webrtc-minutes.html dom
- 17:03:43 [dom]
- RRSAgent, make log public
- 17:28:53 [jib]
- jib has joined #webrtc
- 19:04:51 [Zakim]
- Zakim has left #webrtc
- 20:00:17 [geheimnis`]
- geheimnis` has joined #webrtc