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