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