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