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