23:42:16 RRSAgent has joined #webrtc 23:42:16 logging to https://www.w3.org/2019/09/19-webrtc-irc 23:42:24 scribenick: hta1 23:42:34 Starting with SVC structures. 23:43:01 Decision: Remove drawings from SVC spec; AV1 is normative for drawings. SVC spec is normative for strings; make that clear. 23:43:50 dom has joined #webrtc 23:44:29 Aboba - Presenting on custom scalability modes. 23:45:33 dontcallmeDOM has joined #webrtc 23:45:48 ericc has joined #webrtc 23:45:52 RRSAgent, make log public 23:45:54 RRSAgent, draft minutes 23:45:54 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html dontcallmeDOM 23:46:10 If a different mode is required, we could define a new mode string. Assigning a new number in AV1 requires AOMedia cooperation. 23:46:52 aboba: we could define strings that reference AV1 custom scalability modes if we can define scalability structures using SS. 23:48:47 could also define modes in prose in this spec. 23:50:14 action aboba: Add a paragraph to the table to describe considerations for adding new values to the table of modes. 23:51:26 "new modes can be added to this table by updating this specification". 23:51:46 issue 14 - orphis: Encoding parameters for spatial layers 23:53:33 active, maxBitrate and maxFramerate probably make sense. 23:54:00 yu has joined #webrtc 23:55:03 yuj_ has joined #webrtc 23:55:26 horiuchi has joined #webrtc 23:56:11 youenn: what's the usecase for active? 23:58:34 i/Starting with/Topic: WebRTC-SVC 23:58:53 RRSAgent, this meeting spans midnight 23:59:08 aboba: There's a difference between dropping a layer and changing a mode. 23:59:20 Meeting: WebRTC TPAC F2F Day 2 23:59:32 Chair: Harald, Bernard, Jan-Ivar 00:00:14 Present+ Emad, Aramando, Henrik, Jan-Ivar, Bernard, Youenn, DrAlex, Orphis, Dom, Harald, EricC 00:00:18 RRSAgent, draft minutes 00:00:18 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html dontcallmeDOM 00:03:16 amit: should we value consistency over conformance? Users will use modes that they dont understand, and will be surprised. 00:04:09 hta: People who don't understand the codec and mode they are using are going to have a hard time anyway. 00:05:25 orphis: 00:05:47 youenn: a mode would have a sensible default, used when you don't specify anything. 00:07:00 scribenick:hta 00:09:07 scribenick: hta 00:09:50 (discussing case of bitrate allocation - is percentage right, or is numbers right?) 00:12:42 inamori_ has joined #webrtc 00:13:27 weiler has joined #webrtc 00:14:20 where are minutes being taken? 00:14:23 anssik has joined #webrtc 00:14:46 here. writing slowly. 00:15:03 Zakim has joined #webrtc 00:15:06 present+ 00:15:17 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html weiler 00:16:02 christine has joined #webrtc 00:16:03 dr alex: scaleResolutionDownBy is independent for each layer in simulcast? several: yes, it is relationship to source, not between streams 00:16:05 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html weiler 00:16:55 Amit has joined #webrtc 00:17:52 This discussion will continue at 2PM. 00:17:57 hhan1 has joined #webrtc 00:18:04 Topic: Privacy Issues 00:18:19 ScribeNick: dom 00:18:31 ScribeNick: dontcallmeDOM 00:18:41 [welcoming PING representatives] 00:18:58 Youenn: we want good privacy reviews on our planned Proposed Rec of WebRTC-PC and Media Capture 00:19:00 Gooroomee has joined #WebRTC 00:19:10 Youenn: Issue 612 00:19:53 ... enumerateDevices is a way for Web pages to enumerate all capture devices (camera, mics, speakers) 00:20:06 ... it's meant to help implement a device picker to select a particular camera and microphone 00:20:42 tara has joined #webrtc 00:21:23 present+ 00:21:53 ... that information is gated by device-info permission 00:22:25 ... without that permission, you don't get labels, but you get persistent device ids and that entails the exact number and type of devices 00:22:55 ... our proposal is to hide more info before device-info is granted, only expose generic/low-fingerprint profile of devices 00:23:53 ... In Safari, we've looked at Web pages - most device pickers are only available after getUmserMedia was granted 00:24:11 ... one proposal was to expose one device of each type - that's what Safari ships; it is Web compatible 00:24:32 ... (we haven't received negative feedback since we've shipped this a month ago) 00:24:58 ... this still exposes whether a given device has access to a capture device of given type 00:25:29 ... A second proposal is to lie: pretend there is one capture device of each given type 00:25:31 q+ 00:25:50 ... you get the truth after the gUM prompt 00:25:59 ... this fixes the fingerprinting issue of the 1st proposal 00:26:11 ... a 3rd proposal would be to push enumerateDevices() behind a prompt 00:26:21 ... but that feels difficult to implement (how to make it meaningful to the user) 00:26:31 ... also feels hard from a compat perspective 00:26:58 PeterSnyder: is this actually used for fingerprinting? 00:27:06 Youenn: yes 00:27:19 EricC: and it is used for that a lot more than for getting cameras 00:27:58 Harald: hangout will display a camera icon only if it finds a camera in its chat mode 00:28:13 ... proposal 2 would make that distinction useless 00:28:35 s/hangout/hangout chat/ 00:29:00 Youenn: this would require a change in the UX of hangout 00:29:13 q+ 00:29:27 Sam: what is the deviceId? free-form string? 00:29:30 Youenn: a UUID 00:29:52 JIB: per-origin 00:30:32 Youenn: double-keyed 00:30:41 Dom: what if new capture device types come in? 00:30:58 Harald: e.g. depth cameras which are in the pipeline 00:31:22 Youenn: I think this would have to move to a picker-based approach 00:31:47 Armando: lying about devices availability doesn't sound right 00:32:11 EricC: in Safari, we default to the list of capture devices that are tied to that platform (e.g. 2 cams, 1 mic on iPhones) 00:32:42 ... if there are additional devices, we pretend they come up upon gUM grant 00:32:57 q+ 00:33:03 PeterSnyder: would moving to Proposal 3 in the long term be a possibility? 00:33:11 q- dontcallmeDOM 00:33:35 EricC: what kind of questions would make sense for Option 3? 00:33:51 Sam: one anti-pattern is asking permissions as soon as users get in 00:34:08 ... I've been that in WebRTC land in particular when it comes to asking for cameras 00:34:13 axk wei 00:34:15 ack wei 00:34:32 Bernard: part of the reason this happens is because fewer and fewer features are available before you ask for permissions 00:35:23 ... e.g. network topology detection is gated to camera permission today 00:35:45 ... and as this causes problems to real deployment 00:35:49 q+ 00:36:08 JIB: I doubt going to permission prompt is a direction any browser would go to 00:36:30 ... plus, a permission prompt for enumerating devices would be just before another prompt 00:38:11 Harald: I'm hearing moving towoard Proposal 1 would be acceptable to all implementors 00:38:13 we have 5 issues to get through. We have 45 minutes. 00:38:48 (now we have 22 minutes) 00:39:44 ... Proposal 2 is more controversial 00:39:53 PeterSnyder: I do have concerns with proposal 1 00:40:08 Dom: for clarity, all these proposals are improvements over the current situation 00:40:34 PeterSnyder: Proposal 2 then lies about the reality? when does the truth get revealed? 00:40:47 EricC: upon getting permission access for capture 00:41:00 ... the list of devices would be updated (with an event) to reflect the reality 00:41:35 PeterSnyder: OK, that sounds appealing 00:42:07 Youenn: Proposal 1 is clearly implementable (shipped in Safari) 00:42:39 ... Proposal 2 will break some web sites e.g. if they adapt their default UI to what's available 00:43:58 Youenn: hearing Proposal 1 is a good implementors target in the short term; Proposal 2 is appealing to PING 00:44:17 ... and appealing to some implementors 00:44:31 Youenn: Issue 607 - persistence of device ids 00:44:42 ... can be used for cross-site tracking 00:44:51 ... deviceIds have already some level of protection 00:45:01 ... they're not exposed to cross-origin iframes 00:45:29 ... they can also be hidden from iframes with device-info 00:45:53 ... A proposal is to partition id if other persistent partition id 00:46:52 ... Difficult in making it mandatory today given existing deployment 00:48:14 ... Re partitioning, Safari double-keys all persistent data based on the nesting of browsing context (à la iframe) origins 00:48:34 ... (existing discussions in this space for http cache in fetch spec, and in service workers) 00:48:48 Double keyed HTTP cache: https://github.com/whatwg/fetch/issues/904 00:49:33 PeterSnyder: the concern is when there is no double-keying 00:50:52 Youenn: the goal is to go there; the question is what to do when double-keying is not available 00:51:02 PeterSnyder: I'm suggesting double-keying the seeing of UUID 00:51:15 s/seeing/seeding/ 00:51:29 ... to partition the deviceId space 00:51:58 JIB: this breaks the case of embedded e.g. Hangout 00:52:58 ... and it doesn't actually buy privacy until indexeddb is partitioned 00:54:16 PeterSnyder: PING would be happy with requiring partitioning of deviceID 00:55:17 Youenn: Issue 374 00:55:28 ... WebRTC Stats is exposing for network types from users 00:55:37 ... e.g. if the user is on wifi, ethernet, vpn, etc 00:55:53 ... mostly for debugging purposes 00:56:07 ... the problem is that it exposes fingerprinting surface, expose privacy-sensitive information 00:56:29 ... and could be mis-used for user-hostile adaptation 00:56:59 ... A first proposal would be to move this to an extension spec where special mitigations could be discussed 00:57:19 ... Second: we have already a note about this, nothing needs to be done 00:58:02 ... Third: we hide this behind the getUserMedia 00:58:09 Emad: what's the fingerprinting surface? 00:58:26 Youenn: you can monitor the different types of network a user has been using, when, detect patterns 00:59:02 steveanton has joined #webrtc 00:59:06 @@@: different behavior on different type of networks sounds useful 00:59:24 Dom: not what WebRTC Stats are meant for - they're meant for monitoring or debugging 00:59:26 @@@ = amit 00:59:35 ... UX adaption would need to use e.G. network information 00:59:39 s/@@@/Amit 00:59:49 debugging should be "special case", right? hence it's okay to not provide the info in the ordinary case? 01:01:51 Peter: Network Error Logging is another API that reports information on network traffic 01:01:57 Dom: does it? 01:02:03 Peter: would need to double check 01:03:43 Harald: Proposal A & B doesn't actually change what's shipping 01:03:53 ... C about guidance feels more important 01:05:41 Dom: let's distinguish between the practical considerations of where to define the mitigations 01:05:51 ... I think I'm hearing interest in investigating mitigations in more details 01:06:12 Amit: we could fuzz the network types (e.g. network1, network2, ...) 01:06:52 ... could help distinguishing cases of debugs 01:07:02 Peter: I think that rather guidance is specific rules 01:07:10 Bernard: in practice, vpn isn't all that useful 01:07:44 Christine: vpn are actually forbidden in some countries, this shouldn't be broadcasted 01:07:55 Harald: vpn should just be deleted from what I'm hearing 01:08:51 ... we still need to look at how critical networkType is for debugging purposes given the concerns we're hearing 01:09:46 Henrik: other exposed stats given maybe more actionable (e.g. bitRate) 01:09:57 Dom: proposal D would then be removing it 01:10:01 again, isn't debugging a special case, such that it could be hidden behnd a permission? 01:11:09 Peter: PING would support removing it if that's not too big a loss, gating it would be the fallback 01:11:13 jib has joined #webrtc 01:11:30 we might want qingsi to give an opinion as an expert on ice debugging 01:11:36 Youenn: Issue 83 in audio output 01:11:53 ... We're currently limited to which speakers can be used for audio output 01:12:02 ... as it linked to getting permission to getting audio input 01:12:27 ... We would like to offer an in-chrome picket to give access to new devices 01:12:37 Armando: we're supportive 01:12:45 Peter: without knowing the details, this sounds interesting 01:13:17 Youenn: thank you for all your help 01:13:27 Peter: thank you for having us 01:13:30 RRSAgent, draft minutes 01:13:30 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html dontcallmeDOM 01:20:07 horiuchi has joined #webrtc 01:26:29 horiuchi_ has joined #webrtc 01:27:05 horiuchi_ has joined #webrtc 01:32:09 ericc has joined #webrtc 01:34:12 horiuchi has joined #webrtc 01:35:08 steveanton has joined #webrtc 01:44:47 Amit has joined #webrtc 01:49:21 jib has joined #webrtc 01:49:35 dralex has joined #webrtc 01:49:38 Jared has joined #webrtc 01:49:44 hhan has joined #webrtc 01:49:51 Topic: WebRTC NV Use Cases 01:49:57 ScribeNick: dralex 01:50:32 dralex_ has joined #webrtc 01:50:38 ScribeNick: dralex_ 01:50:39 scribing 01:50:50 14 open issues 01:50:57 ++> issues 53 01:51:11 advanced codec cap. 01:52:11 HW acc available? 01:52:18 min and max resolutions 01:52:28 support for sic ? 01:52:31 svc? 01:53:23 jianjunz has joined #webrtc 01:53:29 Amit_ has joined #webrtc 01:54:51 use case B : identify the implementation (good for debugging, and good for adaptation to a specific implementation features) 01:56:00 annevk has joined #webrtc 02:01:58 in some cases, supported profiles and resolutions are different for HW and software 02:02:30 right now the encoder is assigned during negotiation, and then the bandwidth adaptation might change the setting outside of what the current encoder/decoder can do. 02:02:50 youenn express concerns that from the developer point of view, it can become real hard to handle. 02:04:36 QingAn has joined #webrtc 02:08:35 Action item, henrik will .... 02:09:06 describe one or two uses cases, and then make a PR. 02:09:47 JY: it seems to be presented the wrong wa: API first, instead of use case first. Can you please write the use corresponding use case? 02:11:06 florent: we would like to be in a case where we get helpful error messages to act on it. 02:11:20 dom: that really underline the need to write a user story 02:11:36 JY: we have to be careful not to augment the fingerprinting surface. 02:12:49 -------------- 02:13:04 issue 37: requirement for secure web conferencing. 02:13:07 sudeep has joined #webrtc 02:13:15 second attempt since the meeting in Stockholm 02:13:24 PR 49 submitted by Cullen 02:13:51 google'se mad suggested that we look at the MLS security architecture as an inspiration to write our requirements here 02:17:11 discussion about req. N25 to N29 from MLS 02:18:37 proposal to put that in the secure conferencing requirements 02:22:14 dom recommandatie is to only fuse one of this use case. 02:24:17 mozilla position is to merge in the untrusted case, and needs to think about the trusted case. 02:24:33 google is considering very seriously considering the trusted case and implementing it 02:24:55 apple is not in favour of anything, but shows interest in the result of investigations from mozilla and google. 02:25:09 --------------- 02:25:21 charte expire in march 2020 02:26:03 since a new or updated charter would need 3 months to be approved, we would need a WG-approved draft by EoY 02:28:11 obvious charter changes: 02:28:25 2 secs out (webrtc 1.0, GUM) 02:28:38 update deliverable timelines 02:30:11 horiuchi has joined #webrtc 02:30:22 dralex has joined #webrtc 02:30:31 scribbing 02:30:44 open questions: what do we do with existing deliverables 02:31:03 is there any new deliverable? 02:31:09 how long do we need. 02:33:08 what should we do about the maintenance of webrtc 1.0 and GUM 02:34:11 what about webrtc-stats and webrtc identity 02:37:05 there is also a leak of editor 02:37:18 some people and/or organization need to provide ressources 02:40:55 other specs are stable but much earlier in the standardisation process. 02:41:05 image capture, depth cameras 02:41:07 content hints 02:43:22 dralex_ has joined #webrtc 02:43:47 work could only continue with an identified editor, AND a commitment by a browser vendor to implement 02:44:28 emerging use cases 02:44:33 more granular objects 02:44:36 webrtc insertable 02:44:41 end-to-end encryption 02:45:57 hta1 has joined #webrtc 02:46:02 dralex__ has joined #webrtc 02:49:17 really only three ways forward: 02:49:31 in re-chartered group: only with editor and implementor commitment 02:49:39 in incubation (CG group) 02:49:51 or moved to another group (media group) 03:00:08 horiuchi_ has joined #webrtc 03:02:20 it seems that the consensus is to keep the 3 activities together (maintenance, dev, ....) 03:02:47 the question is open about whether some media capture should follow web transport, webcodec. 03:03:30 the consensus seems that there is a strong link with web transport and webcoedc (peter), but as it would dbe the same implementor as the main webrtc spec, it would make sense to keep things together 03:04:39 interest from mozilla and apple on image capture 03:04:46 no strong interest in depth 03:06:24 stop discussion here because of time questions 03:06:35 RRSAgent, draft minutes 03:06:35 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html dontcallmeDOM 03:21:28 inamori_ has joined #webrtc 03:49:39 hta has joined #webrtc 04:04:52 horiuchi has joined #webrtc 04:06:37 Joshue108 has joined #webrtc 04:06:57 inamori_ has joined #webrtc 04:06:57 jcraig has joined #webrtc 04:07:46 Web RTC group. Dom said to come to the #APA room (the physical room) in Kashi 1F right behind registration 04:10:08 dom__ has joined #webrtc 04:11:07 hta1 has joined #webrtc 04:11:09 present+ 04:11:56 jib has joined #webrtc 04:12:00 youenn has joined #webrtc 04:15:26 [minutes for this meeting taken on #apa] 04:21:47 horiuchi has joined #webrtc 04:23:53 horiuchi_ has joined #webrtc 04:26:35 jj has joined #webrtc 04:31:28 ericc has joined #webrtc 04:39:03 dontcallmeDOM has joined #webrtc 04:40:03 horiuchi has joined #webrtc 04:43:05 vr000m has joined #webrtc 04:51:49 horiuchi_ has joined #webrtc 04:53:41 trying to join the meeting URL is this URL correct: https://meet.google.com/vxf-wgai-rjn 04:57:33 we're having a meeting in a different room at the moment, so I guess nobody's watching the "allow to join" button. 04:57:41 will be back soon. 04:59:48 ok 04:59:54 horiuchi has joined #webrtc 05:00:42 horiuchi_ has joined #webrtc 05:01:26 riju has joined #webrtc 05:05:54 dontcallmeDOM has joined #webrtc 05:06:01 hta1 has joined #webrtc 05:08:19 jib has joined #webrtc 05:08:26 steveanton has joined #webrtc 05:08:38 scribenick: steveanton 05:08:53 Topic: WebRTC stats 05:11:36 vr000m has joined #webrtc 05:11:53 Resolution: issue-365 & issue-470: just remove RTCMediaStreamStats (move to obsolete) 05:13:35 Resolution: issue-437: agreement for proposal 05:15:33 Topic: Issue 398/PR 495 05:15:52 jib: like these members better than those proposed for transceiver stats 05:17:23 hbos: already have per-encoding stats in the outbound-rtp stats, only thing missing is the rid 05:17:38 ... if that's the only thing we want we should just add it to outbound-rtp 05:17:48 ... but if we want more information then we should have a separate dictionary 05:18:05 jib: prefer to just add rid to outbound-rtp 05:18:34 vr000m: if getParameters exists then rid should be sufficient 05:19:22 ... no concrete objection to just adding rid but would prefer consulting with the list to see if the other stats are useful 05:19:55 horiuchi has joined #webrtc 05:19:58 jib: might be a bug in getParameters -- every time you call it transaction id changes 05:20:26 ... which means you don't know if the transaction id changes because of getParameters or an outside change 05:20:39 dom: let's discuss that in a separate issue 05:20:55 Resolution: add rid and confirm that we don't want to add encoding parameters 05:21:43 Topic: issue-401 05:22:49 bernard: along with svc we have a new weird thing of simulcast without different rtp streams 05:23:24 ... when talking about layer we should identify the layer and the mode of the layer 05:23:53 hbos: might just have an index into the svc config array 05:24:23 bernard: need temporal id & spatial id to identify a layer. byte for each would work for every known codec 05:24:39 vr000m: are sid's numbers? 05:24:53 bernard: possible to have sid represent a simulcast encoding 05:25:01 ... could have multiple simulcast encodings in the same rtp ssrc 05:25:25 ... need to describe better what the layer is and what mode it is 05:25:41 vr000m: we should discuss this in another meeting since it's getting complicated 05:26:18 ... can the svc mode change? 05:26:26 bernard: yes, and would affect the number of layers and stats 05:26:48 hbos: does the basic idea of having one svc stats object per layer with these attributes make sense? 05:27:05 bernard: definitely want to know aggregate stats for the entire stream 05:27:16 ... not sure if per-layer loss is useful for congestion control 05:27:34 vr000m_ has joined #webrtc 05:27:45 ... might use the stats to realize after the fact that your behavior was sub-optimal 05:28:03 hta: framesSent and bytesSent seem like enough 05:28:30 jib: inconsistency ... width vs. frameWidth 05:28:40 hbos: because in that dictionary there's a mix of audio and video 05:28:47 ... frame was added to make it clear it's for video 05:29:24 Resolution: henrik should go write a PR and we'll add it 05:29:30 Topic: issue-443 05:33:15 vr000m: isn't the endpoint aware of the deviation of the stats from expectation? 05:33:31 hbos: need to define expectations 05:33:46 vr000m: can do the math. expectation is inter-frame stats 05:33:58 hbos: over what time frame? 05:34:12 alex: expectation changes with sfu 05:34:25 hbos: expectation can change during call (60 fps to 30 fps) 05:34:27 ... shouldn't be reported a glitch 05:34:42 alex: can only define a glitch by knowing what was sent by the peer 05:35:13 hta: calculate the sum of intervals and sum of squares of intervals? allows you to calculate mean and std dev 05:35:19 jib: before or after the jitter buffer? 05:35:30 ... on the sender side there's feature creep 05:35:36 ... where we have stats on the sources 05:35:45 ... worried we are adding stats for playback 05:35:57 hbos: this has to do with received 05:36:00 ... but will be visible in playback 05:36:06 ... don't intend to measure how the video tag works 05:36:19 alex: need to decouple which part of the video playback pipeline is being measured 05:36:46 jib: if we have a stat that reports glitches but don't have any rendering glitches because jitter buffer smoothed it over is confusing 05:37:02 alex: don't want to force the app to query stats too offer 05:37:06 s/offer/often/ 05:37:24 hbos: need to be specific with how glitch is defined 05:37:35 ... getting the feeling we should move towards proposal B 05:37:42 jib: why do we care about glitches before jitter buffer? 05:37:50 hbos: only care about after jitter buffer 05:37:56 ... some existing stats are confusing about this though 05:38:26 varun: want the stat for after the jitter buffer 05:38:43 alex: fps is supposed to be stable by segment 05:38:49 ... there will be a step at some point 05:38:58 ... can we report the stability of fps within segments? 05:39:16 hbos: that would show up as a glitch in proposal B 05:39:33 alex: can infer expectation by assuming fps is constant for a period of time 05:40:16 hta: sum of square intervals allows you to calculate the average/std dev of arrival rate between any two samples 05:40:33 hbos: that sounds like it would solve the problem 05:40:44 Resolution: add a stat which is the sum of the square of inter frame intervals 05:40:52 Topic: issue-440 05:42:01 hbos: implementation has separate booleans but they are not independent 05:42:06 alex: but this isn't implementation specific 05:42:15 armax: proposal C: remove? 05:42:33 hbos: chrome reports cpu over bandwidth if both are true 05:43:06 discussion about what is the use case for this stat 05:43:51 varun: cpu limiting is interesting when it happens 05:44:10 ... bandwidth limiting we have a lot of other stats 05:44:21 ... cpu is influenced by unknown things on the system 05:44:31 RRSAgent, draft minutes 05:44:31 I have made the request to generate https://www.w3.org/2019/09/19-webrtc-minutes.html dontcallmeDOM 05:45:14 hbos: issue is not about having this stat but what to do when both value apply 05:45:24 jib: if the value is none you can infer that quality is fine 05:45:51 hbos: any value other than none indicates you are not sending the resolution you want 05:46:09