00:12:35 <RRSAgent> RRSAgent has joined #wicg
00:12:35 <RRSAgent> logging to https://www.w3.org/2019/09/19-wicg-irc
00:13:17 <Travis> .. joining the meeting in progress
00:13:37 <Travis> SubTopic: Support for certs not anchored to WEb PKI (Self-signed)
00:14:14 <Travis> ..
00:14:32 <Travis> SubTopic: provide a way to specify a subprotocol
00:14:53 <Travis> It's not trival to find a place to put this in the protocol.
00:15:42 <Travis> Thought: put in first string, but not block data.
00:15:51 <Travis> Could do this without losing RTT
00:17:03 <Travis> But don't want to add extra complexity
00:23:28 <Travis> Two other issues not covered: conjestion control and stream prioritization
00:24:13 <iclelland> iclelland has joined #wicg
00:24:32 <wonsuk> wonsuk has joined #wicg
00:24:54 <yoav> q?
00:25:18 <jbroman> Topic is now WebCodecs
00:25:26 <jbroman> Peter Thatcher: does anyone want an intro?
00:25:31 <Travis> Scribe: jbroman
00:25:32 <jbroman> (response is yes)
00:25:46 <yhirano_> yhirano_ has joined #wicg
00:26:01 <jbroman> low-level API for media encode/decode
00:26:08 <jbroman> based on transform streams
00:26:33 <jbroman> useful for live streaming, faster-than-realtime encoding, realtime comms, ...
00:27:04 <jbroman> VideoEncoder takes image data and makes a bitstream
00:27:23 <jbroman> typically gotten from a MediaStreamTrack via VideoTrackReader
00:27:43 <jbroman> not strictly part of web codecs but pulled in as a dependency
00:28:29 <jbroman> slide example of constructing audio/video decoders from some readable streams
00:28:40 <jbroman> and plugging that into a <video> element
00:29:08 <jbroman> slide example of using this to transcode media by piping between decoder and encoder
00:29:10 <Travis> q+ to ask about codec discovery if not covered in the presentation...
00:30:14 <jbroman> slide comparing to MediaRecoder: more low-level, ...
00:30:36 <jbroman> similar comparison to MSE
00:31:07 <jbroman> comparison to WebRTC: more low-level, not tied to network transport, can choose what kind of transport you want
00:31:17 <jbroman> buffering is done by the application, not browser
00:31:31 <jbroman> all of this can be done by wasm but this is faster and more power-efficient
00:31:44 <jbroman> access to hw encode/decode
00:32:14 <jbroman> track reader/writer would be useful for wasm codecs too, avoids having to use <canvas>
00:32:35 <yoav> q+ on images
00:32:43 <jbroman> proposal, explainer and webidl but no spec
00:32:46 <jbroman> impl starting soon in chromium
00:32:47 <jbroman> q?
00:32:52 <jbroman> ack Travis
00:32:52 <Zakim> Travis, you wanted to ask about codec discovery if not covered in the presentation...
00:33:10 <jbroman> Travis: can you enumerate supported codecs?
00:33:20 <jbroman> Peter Thatcher: that's the first issue under capabilities
00:33:36 <jbroman> we want to use media capabilities; don't want to duplicate it
00:33:45 <jbroman> there are specific needs to add to capabilities
00:33:59 <jbroman> e.g. low latency vs b-frames
00:34:12 <jbroman> a lot of people want to explicitly choose hw or sw encoder, since some hw encoders are bonkers
00:34:29 <jbroman> for low-level things like svc, there is no support inside MediaRecorder or MSE but we want it
00:34:45 <jbroman> concerned about expanding the fingerprinting surface by telling more to the app
00:34:59 <jbroman> Travis: have you approached them?
00:35:08 <jbroman> Peter Thatcher: yes, and they're engaging
00:35:16 <jbroman> Travis: agree with general sentiment
00:35:17 <jbroman> q?
00:35:19 <jbroman> ack yoav
00:35:19 <Zakim> yoav, you wanted to comment on images
00:35:34 <jbroman> yoav: you mentioned image encode/decode; I suspect this will be an ask
00:35:43 <jbroman> what is the current status?
00:35:57 <jbroman> Peter Thatcher: there was a lengthy discussion; even made a pr
00:36:15 <jbroman> the more we dug into the use cases people wanted, it became unclear whether it was worth it vs wasm or having a one-frame video
00:36:20 <jbroman> currently consider it out of scope
00:36:38 <jbroman> it occurred after a <img>/<video> discussion yesterday that if we could take decoder output and put it in an <img> that would be good
00:36:51 <dharani> dharani has joined #wicg
00:37:00 <jbroman> yoav: I think img/video discussion is different because if app developers are involved, they can just have a muted <video> in all cases except background-image
00:37:08 <jbroman> in background-image case this solution wouldn't help anyway
00:37:25 <jbroman> I don't think that covers the use cases people have when they want to put videos into <img> elements
00:37:36 <jbroman> you're probably correct that people can do things with one-frame videos
00:37:47 <jbroman> at least in image formats today
00:37:58 <jbroman> there might be an image format in the future that is not 100% identical to video format even if inspired
00:38:05 <jbroman> why does it matter if it's one-frame video or image format?
00:38:13 <jbroman> Peter Thatcher: one interesting case is gifs
00:38:22 <jbroman> somebody wanted to encode (animated) gifs
00:38:26 <jbroman> yoav: as an encoding output?
00:38:28 <jbroman> Peter Thatcher: yes
00:38:31 <jbroman> would we call that a video?
00:38:38 <jbroman> there is no containerization right now
00:38:44 <jbroman> is there such a thing as a containerized gif?
00:38:59 <jbroman> images always have containerization; for video it's nice to have bistream w/o container
00:39:03 <jbroman> yoav: ok
00:39:05 <jbroman> q?
00:39:13 <jbroman> Steve Anton: in summary it seemed like scope creep
00:39:21 <jbroman> can do image encode/decode with current apis
00:39:35 <jbroman> yoav: would be interested to hear the use case for gif; do we really want more animated gifs?
00:39:43 <jbroman> ???: lots of internet traffic is memes
00:40:00 <jbroman> Travis: drill into answer about existing way to do image encode
00:40:06 <jbroman> Steve Anton: you can write it to a canvas
00:40:36 <jbroman> Travis: want to be able to bring image payload down from server and decode it later, and recapture the memory later if it goes out of view
00:40:42 <jbroman> want to manage that at a fine-grained level
00:40:53 <jbroman> rbyers: didn't we recently ship something like that (jsbell?)
00:41:04 <iclelland> iclelland has joined #wicg
00:41:33 <jbroman> rbyers: HTMLImageElement.decode; forces eager decode
00:41:41 <jbroman> Travis: can you provide user-defined codec?
00:41:47 <jbroman> Peter Thatcher: yes, injectable codecs
00:42:06 <jbroman> can use simd extensions to wasm etc, but need to get it into/out efficiently
00:42:12 <jbroman> that's where track reader/writer comes into play
00:42:18 <jbroman> we discussed this at a breakout session
00:42:26 <jbroman> want to allow injectable codecs in WebRTC API
00:42:31 <jbroman> Travis: can this be done off-thread?
00:42:38 <jbroman> Peter Thatcher: should be possible, in a worklet
00:42:55 <jbroman> Steve Anton: Web Codecs is more about exposing the platform codecs
00:43:11 <jbroman> though there is interest in allowing injectable codecs in MSE, etc
00:43:23 <jbroman> it is more relevant to those APIS than to Web Codecs
00:43:55 <jbroman> Amit: don't you want it to work the same way as web codecs?
00:44:12 <jbroman> Peter Thatcher: similar API shape, could use Web Codecs or custom codecs
00:44:22 <jbroman> Steve Anton: could imagine constructing a codec on a worker, using it on main thread, etc
00:44:49 <jbroman> s/Amit/Amit Hilbuch/
00:45:04 <jbroman> Peter Thatcher: Next issue: some codecs require extra out-of-band data, like H.264 SPS/PPS
00:45:27 <jbroman> ???: isn't this usually embedded in the container?
00:45:40 <jbroman> Steve Anton: could be, yes
00:45:57 <jbroman> Peter Thatcher: usually extracted from container format and then passed to decoder
00:46:15 <jbroman> (example shows it passed as options to the VideoDecoder ctor
00:46:16 <jbroman> )
00:46:40 <jbroman> Steve Anton: this is data necessary for decoder itself
00:46:54 <jbroman> Amit Hilbuch: should these be specified in IDL or be freeform?
00:47:05 <jbroman> Peter Thatcher: in WebRTC we have key-value pairs; would probably mimic that
00:47:11 <jbroman> Steve Anton: settings are codec-specific
00:47:31 <jbroman> Amit Hilbuch: agree, wouldn't want to bake specific codec parameters into web standard
00:48:08 <jbroman> Steve Anton: is it fine to specify statically at decoder construction, or would they need to change later on, e.g. per-chunk
00:48:31 <jbroman> Amit Hilbuch: how are these different from ???
00:48:41 <jbroman> Steve Anton: distinction between things needed to understand bitstream vs encoder hints
00:49:28 <jbroman> Steve Anton: are there parameters needed to understand the bitstream that are not known when the decoder is constructed?
00:49:33 <jbroman> need to consult codec experts
00:49:41 <jbroman> Peter Thatcher: next issue: decoding b-frames
00:49:55 <jbroman> in video codecs there are dependencies between frames
00:50:00 <jbroman> b-frames depend on future frames
00:50:03 <jbroman> need to decode out of order
00:50:12 <jbroman> how do we support this in the decoder api?
00:50:20 <jbroman> yoav: buffering?
00:50:45 <jbroman> Peter Thatcher: require JS to handle it by getting it in decode order; JS can reorder after
00:50:55 <jbroman> but hardware decoders reorder internally
00:51:07 <jbroman> Steve Anton: feels like most decoders could efficiently reorder for you
00:51:11 <jbroman> even sw decoders
00:51:23 <jbroman> Peter Thatcher: do we make the API such that decoders can do it more efifciently?
00:51:32 <jbroman> so far we've added a timestamp to the info going into the decoder
00:51:37 <jbroman> so that it can do the buffering
00:51:41 <jbroman> but if you opt into low latency
00:51:46 <jbroman> then this timestamp would be unimportant
00:51:58 <jbroman> Steve Anton: requiring timestamps doesn't seem too onerous if you don't need them
00:52:01 <jbroman> can just increment by 1
00:52:08 <jbroman> Travis: seems like surrogate pairs
00:52:12 <jbroman> where it's useless to get half of it
00:52:21 <jbroman> almost always just want full character in e.g. HTML parser
00:52:40 <jbroman> is the b-frame an implementation detail, or does it need to be exposed?
00:52:49 <jbroman> Steve Anton: wouldn't get partial images; just get frames out of order
00:52:57 <jbroman> would get keyframe and then partial frames that come before
00:53:14 <jbroman> would the decoder expose the keyframe or wait until after the delta frames have been emitted
00:54:09 <jbroman> yoav: I would ask developers (a) is there an actual use case to get the frames out of order? (b) what is their preference? do they want the API to magically handle that or not?
00:54:17 <jbroman> Peter Thatcher: that's a good idea to ask on discourse
00:54:21 <jbroman> pretty sure I know what they will say
00:54:31 <jbroman> "do you want to do extra work or do you want us to?"
00:54:41 <jbroman> yoav: would it be more efficient in some way if it's done in js? doesn't seem so
00:54:55 <jbroman> ???: which timestamp?
00:55:01 <jbroman> Peter Thatcher: presentation timestamp
00:55:27 <jbroman> Peter Thatcher: next issue: complex coding modes
00:55:32 <jbroman> e.g. SVC
00:55:37 <jbroman> SVC is Scalable Video Coding
00:55:44 <jbroman> progressive images, but for video
00:55:49 <jbroman> different "layers" that depend on each other
00:55:59 <jbroman> useful in real-time communication, e.g. video conferencing
00:56:13 <jbroman> surprised it hasn't been popular in livestreaming
00:56:19 <jbroman> Steve Anton: also useful in offline playback
00:56:30 <jbroman> Peter Thatcher: with only a portion of the bitstream, can decode a lower-quality version
00:56:40 <jbroman> yoav: how does that work wrt video length?
00:56:45 <jbroman> is it "for every x frames"?
00:57:23 <jbroman> (overlapped discussion about how this is implemented, and complicated diagrams in a spec)
00:57:36 <jbroman> Peter Thatcher: simple case has bigger frames dependent on smaller frames
00:57:40 <jbroman> yoav: okay, so each frame is progressive
00:57:47 <jbroman> Peter Thatcher: but it can get more complicated
00:57:51 <tantek> tantek has joined #wicg
00:57:54 <jbroman> Steve Anton: SVC is similar to JPEG progressive decode
00:58:12 <jbroman> Peter Thatcher: from encoder API standpoint, put in 1 frame and get out n frames for same timestamp
00:58:15 <tantek> RRSAgent, make logs public
00:58:31 <jbroman> dependencies between them
00:58:36 <jbroman> similar to time dependencies in normal delta frames
00:58:42 <jbroman> but this impacts the api
00:58:51 <jbroman> when decoding, get different frames for same timestamp
00:59:03 <jbroman> maybe you get a higher-quality frame after having rendered the lower-quality frame
00:59:16 <jbroman> 1 frame in - 1 frame out no longer applies
00:59:21 <jbroman> have tried to integrate into the api
00:59:29 <jbroman> but expressing how you want it set up can be complex
00:59:39 <jbroman> expressing what is possible through media capabilities is also complex
00:59:47 <jbroman> yoav: is there a preference
01:00:00 <jbroman> e.g. I'm a low-power device, only want partial layers?
01:00:11 <jbroman> but client and server could have communicated that
01:00:27 <jbroman> Peter Thatcher: in real-time comms, client asks for higher res version that is available according to network conditions
01:00:36 <jbroman> yoav: device could say max quality it can handle
01:00:45 <jbroman> Amit: that's in signaling
01:00:54 <jbroman> yoav: maybe in media capabilities you want to know what's possible
01:01:05 <jbroman> Peter Thatcher: might have a limit in how many layers you can do
01:01:10 <jbroman> not just for video
01:01:15 <jbroman> in audio, opus fec
01:01:28 <jbroman> particular packet can contain current time's high quality audio and previuos time's low quality audio
01:01:36 <jbroman> so if you miss a packet you can fill in with the low quality version
01:01:54 <jbroman> so from an opus bitstream you can decode either high or low quality data
01:02:03 <jbroman> Steve Anton: might be able to figure it out automatically
01:02:07 <jbroman> based on gaps in timestamps
01:02:11 <jbroman> Peter Thatcher: good point
01:02:14 <jbroman> could treat it like SVC
01:02:28 <jbroman> if you get the earlier one first and high quality one later, get a second audio frame at the same time
01:02:37 <jbroman> Steve Anton: at encode side, just need a way to turn it on
01:02:40 <jbroman> Peter Thatcher: agreed that it's easy
01:02:46 <jbroman> decode is what's interesting
01:03:11 <jbroman> Steve Anton: with SVC, multiple layers make up one frame
01:03:17 <jbroman> if you expect to get all the layers you want to wait
01:03:37 <jbroman> might need a way to flush what's currently available
01:03:56 <jbroman> yoav: how can we facilitate this in the futuree?
01:04:05 <jbroman> Peter Thatcher: might not want to implement all of this now
01:04:13 <jbroman> but don't want to paint ourselves into a corner
01:04:18 <jbroman> Steve Anton: can't assume frame in, frame out
01:04:30 <jbroman> yoav: at the same time, a future application using those coding modes will be aware of it
01:04:38 <jbroman> they will know that multiple frames can come out, etc
01:05:00 <jbroman> Peter Thatcher: skipping Timestamps and time domains because Paul isn't here
01:05:42 <jbroman> short version: when we go from readable streams to tracks, for audio want to give it to OS as needed; for video to keep it smooth you want to say when a video frame is presented
01:06:01 <jbroman> if you just take frames from decoder as fast as they come out, it might not be smooth
01:06:12 <jbroman> ???: might need to drop frames to keep smooth?
01:06:31 <jbroman> Peter Thatcher: how do you decide which frame goes out on a particular vsync?
01:06:48 <jbroman> if we put JS in complete control, prone to JS pauses
01:06:59 <jbroman> Steve Anton: concern already exists e.g. with WebGL
01:07:05 <jbroman> so might not be intractable
01:07:12 <jbroman> Peter Thatcher: might not be clear until we try to implement
01:07:15 <jbroman> Paul has better ideas
01:07:41 <jbroman> Todd: expected to be done off render thread?
01:07:57 <jbroman> Peter Thatcher: yes; still may want to control what frame goes out on what vsync
01:08:03 <jbroman> Todd: sounds like it might be more efficient
01:08:19 <jbroman> Peter Thatcher: if latency isn't as important, buffering to provide smoothness might be more important
01:08:23 <jbroman> vs real-time use cases
01:09:15 <Travis> Thanks jbroman !
01:09:20 <jbroman> Topic: information pipeline between WICG and web developers
01:09:30 <jbroman> yoav: don't know if this is interesting to non-chairs
01:09:41 <jbroman> Todd: what is the core of the question?
01:09:56 <jbroman> yoav: I think discourse today is mostly used as a "bring us your proposal" forum
01:10:01 <jbroman> not the most effective way to get stuff done
01:10:27 <jbroman> would be interesting to use it more, or use another means more, to get use cases from developers
01:10:31 <jbroman> and then iterate over API shape questions
01:10:46 <jbroman> Todd: when you say use cases, you mean problems that are difficult or impossible to solve?
01:10:51 <jbroman> and exactly what are you trying to do?
01:10:58 <jbroman> rather than "I dreamed of this API shape"
01:11:10 <jbroman> yoav: is that worthwhile to discuss in this forum?
01:13:45 <jbroman> cwilso: is discourse the right entry point to wicg, or would something else make more sense? I drew the parallel in the AC meeting; there is 1:1 overlap between ???. The way we start things up is similar to WICG. We ask to see evidence that >1 person cares about this problem to give it legitimacy. Immersive Web Group has specific "proposals" repo. File an issue; everyone follows this repo. Sometimes we still have competing repos about interesting
01:13:45 <jbroman> ideas. That's how we do it; we barely use our mailing list. Would that be easier than using discourse?
01:14:16 <jbroman> I don't go to discourse often
01:14:20 <jbroman> Travis: but you do go to github often
01:14:35 <jbroman> cwilso: I do, but don't necessarily dig into the right repo every day
01:14:46 <jbroman> Todd: how to keep web developers engaged, understand what are the issues?
01:15:02 <jbroman> cwilso: process for starting in WICG is intended to be easy but still have a minimum bar
01:15:12 <jbroman> we do ask that every incubation proposal has >1 organization
01:15:21 <jbroman> if 15 Google employees say it's a good idea, that's not good enough
01:15:29 <jbroman> but 1 web dev + 1 MS employee, that's good enough
01:15:38 <jbroman> some measure of cross-industry interest
01:15:44 <jbroman> are we using the right mechanism for that?
01:15:50 <Guest19> Guest19 has joined #wicg
01:16:00 <jbroman> yoav: there's the question of engagement, and beyond that, once you've got people engaged, what do you actually want from them?
01:16:23 <jbroman> I think that I traditionally try to get web devs more involved in standards, but it may have been a mistake in the sense that people don't necessarily have time to do that on top of their job
01:16:50 <jbroman> at the same time, an engagement that says "here is a problem space we're looking at; give us your use cases and pain points"
01:17:04 <jbroman> and they just have to write 100 words and leave and don't have to follow up as a long-term commitment
01:17:13 <jbroman> that is something that developers are actually likely to be interested in doing
01:17:17 <jbroman> if we make it easy/welcoming enough
01:17:35 <jbroman> Travis: I wonder how much a developer feels like they get to be a part of it if they just pop in, make a suggestion, and never come up
01:17:38 <jbroman> what's missing is the follow-up
01:17:44 <jbroman> that we turned your random idea into something complete
01:17:48 <jbroman> wdyt? does it still work?
01:17:59 <jbroman> How can we make sure that's working unless we keep them engaged?
01:18:01 <jbroman> yoav: discourse, github
01:18:24 <jbroman> once we have some API shape, we can ask them if it would address their use case or not
01:18:35 <jbroman> we can try to have long-term engagement in terms of revalidating use cases, API shape, etc over time
01:18:37 <jbroman> until shipped
01:18:41 <jbroman> but doesn't require them to do a ton of work
01:18:55 <jbroman> Travis: could be done through discourse or github, orthogonal to the question?
01:18:59 <jbroman> yoav: not a tooling question
01:19:14 <jbroman> do we want to take that approach? can pick a tool after that
01:19:31 <jbroman> chairs, does that make sense as a browser developer?
01:19:46 <jbroman> Steve Anton: web developers have a hard time getting excited about proposals
01:19:50 <jbroman> they seem so far off
01:19:52 <jbroman> first step is use cases
01:19:58 <jbroman> devs happy to talk about use cases
01:20:19 <jbroman> there's a gap where it's hard to get them involved in middle stages
01:20:21 <jbroman> until origin trial
01:20:43 <jbroman> cwilso: early part of "Web dev has a use case" is outside of this
01:20:52 <jbroman> more like "web we want" effort
01:21:08 <jbroman> let's turn early use cases into actionable problem statements for further incubation
01:21:12 <jbroman> so many people come up with problems
01:21:21 <jbroman> but thinking about how to solve in a broader space is hard sometimes
01:21:42 <jbroman> I'm more concerned about having an active set of people, how do we get more people engaged in solution efforts?
01:21:51 <jbroman> yoav: define "engage in solution efforts"
01:22:00 <jbroman> cwilso: iterating on problem statements, solutions in incubation process
01:22:28 <jbroman> a number of incubations had people saying it was interesting, turns into one person creating, proposing, implementing, experimenting w/o a lot of engagement
01:22:29 <jbroman> that's tough
01:22:39 <jbroman> not saying that's a totally broken pattern but shouldn't be the usual pattern
01:22:55 <jbroman> Todd: if there are 5 people on discourse saying it's a good idea and one person begins work, how do all 5 people contribute?
01:23:03 <jbroman> cwilso: even continually engaging after that
01:23:12 <jbroman> one downside of discourse is that it's for initial stages only
01:23:18 <jbroman> once there's a repo, it's disconnected from discourse
01:23:25 <jbroman> conversation moves into a different tool altogether
01:23:29 <jbroman> that seems odd
01:23:44 <jbroman> Peter Thatcher: with Web Transport, had some people interested; wanted to have community discussion
01:23:50 <jbroman> wasn't sure whether to use discourse, github, mailing list, ?
01:23:56 <jbroman> lack of a way to keep interested people in the loop
01:24:07 <jbroman> Todd: does an individual effort have a single discourse thread?
01:24:16 <jbroman> cwilso: usually one, but once repo created there's no conversation there
01:24:29 <jbroman> Todd: a bot to update discourse thread with # issues created etc?
01:24:35 <jbroman> yoav: there are also labels
01:24:53 <jbroman> theoretically you could have multiple threads and have them labelled
01:25:02 <jbroman> Todd: do we think the discourse thread don't go to the github
01:25:06 <jbroman> or do they not know? not have time?
01:25:08 <jbroman> do we know why/
01:25:12 <jbroman> cwilso: we don't truly know why
01:25:25 <jbroman> part of it is that it's a barrier that we need to see engagement to create the repo
01:25:32 <jbroman> engagement beyond that is a long-term interest thing
01:25:38 <jbroman> human nature to have limited time/effort to expend
01:25:57 <jbroman> superstar is co-chair Marco (sp?) who comments on everything which is great
01:26:15 <jbroman> suspect if we used GitHub as that comm tool it might be easier to get interest from other people
01:26:25 <jbroman> we could manage tagging/labelling things in the proposals repo
01:26:33 <jbroman> so people could follow e.g. styling or networking proposals
01:26:48 <jbroman> Todd: replacing  disocurse with github?
01:26:50 <jbroman> cwilso: yeah
01:26:55 <jbroman> s/disocurse/discourse/
01:27:34 <jbroman> Peter Thatcher: when people were interested in Web Transport/Codecs, had to tell people to come to discourse page and people weren't familiar
01:27:50 <jbroman> maybe GitHub would be better
01:28:04 <jbroman> yoav: one way to resolve question would be to ask it
01:28:09 <jbroman> do a survey
01:28:20 <jbroman> provide multiple engagement mechanisms and ask that they would prefer
01:28:25 <jbroman> discourse vs github vs ??? with examples
01:28:52 <jbroman> Peter Thatcher: have you talked to foms (sp?); they have engagement from web devs about media stuff
01:29:04 <jbroman> whatever they're doing seems to do a good job
01:29:23 <jbroman> Todd: web performance wg has attended velocity conference (now renamed)
01:29:26 <cwilso> s/foms/FOMS: http://www.foms-workshop.org/foms2019SF/
01:29:40 <jbroman> that did get some engagement
01:29:52 <jbroman> yoav: view source next week would get a good place to collect anecdata
01:29:56 <jbroman> cwilso: we should wrap up
01:30:06 <Travis> RRSAgent: make minutes
01:30:06 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/19-wicg-minutes.html Travis
01:30:17 <Travis> thanks Zakim
01:31:38 <iclelland> iclelland has joined #wicg
01:49:11 <iclelland> iclelland has joined #wicg
02:02:43 <iclelland> iclelland has joined #wicg
02:05:15 <aboxhall_> aboxhall_ has joined #wicg
02:06:30 <ericc> ericc has joined #wicg
02:23:47 <jihye> jihye has joined #wicg
02:51:12 <Zakim> Zakim has left #wicg
03:02:48 <ericc> ericc has joined #wicg
03:15:46 <iclelland> iclelland has joined #wicg
03:49:32 <iclelland> iclelland has joined #wicg
03:52:00 <iclelland> iclelland has joined #wicg
04:02:16 <iclelland> iclelland has joined #wicg
04:13:53 <ericc> ericc has joined #wicg
04:34:59 <ericc> ericc has joined #wicg
05:34:24 <Guest19> Guest19 has joined #wicg
05:45:43 <onix> onix has joined #wicg
05:48:55 <tiger> tiger has joined #wicg
06:06:03 <iclellan1> iclellan1 has joined #wicg
06:07:04 <bkardell_> bkardell_ has joined #wicg
06:28:19 <iclelland> iclelland has joined #wicg
06:30:22 <tantek> tantek has joined #wicg
06:37:18 <ericc> ericc has joined #wicg
07:53:26 <iclelland> iclelland has joined #wicg
07:57:43 <iclellan1> iclellan1 has joined #wicg
08:21:47 <tantek_> tantek_ has joined #wicg
08:28:34 <iclelland> iclelland has joined #wicg
09:29:46 <Rossen> Rossen has joined #wicg
09:31:17 <leaverou> leaverou has joined #wicg
10:57:02 <Guest19> Guest19 has joined #wicg
12:28:13 <iclelland> iclelland has joined #wicg
13:40:57 <iclelland> iclelland has joined #wicg
14:33:02 <iclelland> iclelland has joined #wicg