18:00:03 #startmeeting 18:00:03 Meeting started Thu Sep 3 18:00:03 2020 UTC. The chair is paddatrapper. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:06 yay 18:00:20 #topic Roll call 18:00:22 (there's this thing called #chair :P) 18:00:24 o/ 18:00:29 yo yo in da house 18:00:30 \0 18:00:38 Agenda: http://deb.li/oNCD 18:00:54 nattie: yo-yos also work outside in the garden :P 18:01:02 o/ 18:01:04 o/ 18:01:38 #topic DC20 Review 18:02:07 DC20 worked out pretty well, for a start 18:02:07 :) 18:02:21 Feedback pad - https://storm.debian.net/shared/c_q9vqo2cciXrJ-iI7AdI5pzavfF0HwRQqjC3yELotz 18:02:32 Yeah I think it worked out very well 18:02:41 it was nice to be using etherpad for a while 0:-) 18:02:48 * olasd ducks 18:03:01 wait, there's another question on the etherpad! 18:03:02 storm will be faster soon™ 18:03:05 I'm in work meeting, but will keep an eye to see if there's anything where my input is useful 18:03:34 remember how worried everyone was each time I talked about adding OBS to the stack? 18:03:38 times OBS crashed: 0 18:03:59 #topic DC20 Review - recordings status 18:04:02 the vm it was running on was... quite overpowered ;) 18:04:10 overpowered is good. 18:04:21 Do we know where the reviews are currently? Are there more to do? 18:04:38 I gave up trying to answer that question 18:04:49 we've had reports of some talks missing, and of some talks being misnamed 18:04:58 I have no idea what is in what state 18:05:03 #info Some talks missing from archive and some being misnamed 18:05:18 I've seen some reviews happening for the Malayalam track earlier this week 18:05:20 tumbleweed: have you started uploading to YT ? 18:05:26 well I did 18:05:33 but then some things got reencoded 18:05:42 and it was stated that everything was going to get reencoded 18:05:44 oh interesting I thought that usually only happens once they're all finighe 18:05:48 so, shrug? nafc what's going on 18:05:49 finished 18:06:04 highvoltage: normally, we'd try to get videos finished within a day or two of the talk 18:06:10 #info YT uploads pending resolution of current state 18:06:23 Ok, then not much else we can do here but wait for wouter 18:06:31 #topic DC20 Review - Jitsi 18:06:51 Having a seperate room for each talk seemed to work well for the most part 18:07:01 Directors kept forgetting to stop the stream at the end though 18:07:16 having extra jibris (and the 10 minute timeout) helped there 18:07:24 *nod* 18:07:40 the fact that live streaming doesn't end when everyone (who's not jibri) leaves the room is quite counterintuitive 18:07:47 +1 18:08:01 #info extra jibris helped mitigate directors forgetting to stop the stream 18:08:01 I... (hmm should I even mention this now)... 18:08:18 am also looking at potentially replacing jibri with OBS :) 18:08:19 olasd: we should be able to set the timeout to a minute or so from the next Jibri release 18:08:25 paddatrapper: definitely 18:08:34 I mean, definitely we should do that 18:09:14 I would like to look at janus as a potential replacement, with WebRTC -> RTMP streaming application without all the bulk of Chrome 18:09:17 highvoltage: still not convinced that's actually a step forward - don't see jibri itself as being problematic 18:09:25 +1 18:09:29 sorting out authentication for jitsi (and whatever streams it) is quite important too imho 18:09:46 +1 18:09:50 i'm not so sure after all 18:09:58 people will need to share the password 18:10:01 tumbleweed, pollo: I know, I'm hoping you feel different once you see it working 18:10:02 auth wasn't really an issue at dc20 18:10:08 how is it different from a URL? 18:10:20 my main want for the jitsi side is being able to get the real-time stream in it 18:10:25 pollo: URLs are much easier to leak, for one 18:10:29 people are more hesitant pasting passwords into IRC chats 18:10:52 olasd: yeah, wholesale replacement of jitsi with something tailor-made for conferences would be nice 18:11:07 olasd: yeah, that is important (and something using Janus as the backend could do fairly easily, I already have the code to do half of it) 18:11:20 * tumbleweed expected significatly more jitsi URL leaking than actually happened 18:11:26 I assumed quiet bofs would just post the URL in IRC 18:11:27 *nod* 18:12:27 anything more to be added? 18:12:28 paddatrapper: I'm not sure everyone understands how the janus stuff works, (well, I for one don't), do you think you could give us an intro some time? 18:12:46 There is some re-architecting I want to look at for Billowconf, but hopefully that could serve some of these requirements 18:13:28 highvoltage: sure. The TL;DR is that it uses pure WebRTC with HTTP as the side-channel for client-server comms 18:13:44 does it do any video mixing? 18:14:17 no. It is a SFU (selective forwarding unit), so clients receive the feeds they subscribe to 18:14:36 kk no more questions for now 18:15:19 #agreed need to get real-time stream feed into Jitsi 18:15:55 #topic DC20 Review - Voctoweb 18:16:01 I think that comes with a bunch of complexity, but... :P 18:16:09 (I mean, avoiding feedback etc.) 18:16:21 I suspect that's best accomplished by not using jitsi 18:16:25 (you could also share an rtmp stream from a hosted web browser into jitsi. might be 1-2s behind but still ok) 18:16:33 (#undo maybe) 18:16:37 (or hosted vlc) 18:16:38 #undo 18:16:38 Removing item from minutes: 18:16:41 olasd: yeah 18:16:44 can we move on? 18:16:57 highvoltage: still, feedback risk 18:17:03 yeah we can talk more about that topic later 18:17:07 what we did from SotM was a windowed projector from OBS captured into Jitsi 18:17:10 if the point is for the speakers to know when to start speaking 18:17:17 it can't really be playing in jitsi, without getting feedback 18:17:35 the projector only had the recorded talk source available to it, so no feedback 18:17:46 that makes more sense 18:17:56 #topic DC20 Review - Voctoweb 18:17:56 directors gave a countdown 18:17:58 worked well 18:18:17 voctoweb was great, thanks tumbleweed! 18:18:20 I should follow-through on the rename now 18:18:28 and decide how much more time I want to spend on it... :P 18:18:33 +1, voctoweb worked very well 18:18:45 #agreed VoctoWeb worked very well 18:18:51 playback started to get into the territory where it starts to feel easier to just replace voctocore entirely 18:18:57 I am *so* glad we didn't have to VNC and use usual voctomix for this 18:19:12 and it was nice being able to see who else is logged in and who's doing what in the event log 18:19:22 highvoltage: definiteiyl. VNC with SotM was a nightmare 18:19:35 tumbleweed: I wonder how much of it would be reusable with voc2mix 18:20:14 olasd: I haven't seen an overview of what's new in voc2mix 18:20:24 neither 18:20:28 but architecturally ,it doesn't look like things have changed that much 18:20:53 From our experience, I don't think seeking is needed 18:21:07 inter -> interpipe is the big change 18:21:10 With the fallback script we can fix errors 18:21:17 I think there was one time when a video was restarted 18:21:18 did we ever use it? 18:21:25 (the fallback script) 18:21:27 Not that I'm aware of 18:21:30 neither 18:21:32 might be nice to be able to specify a starting position for a video at the play menu 18:21:40 that would be fairly simple 18:21:44 it's the seeking during playback that's hard 18:21:51 (in case it restarted say, at 30m, in this case it was just a minute or so so not a trainsmash) 18:22:13 *nod* 18:22:18 I think allowing seeking provides more opportunity for things to go wrong that actual use 18:22:25 +1 18:22:27 and seeking still seems doable, I just never found my bug 18:22:44 "oops, scroll wheel focus wrong, just seeked through the talk" 18:22:49 lol 18:23:11 I've stopped counting how many times that has happened to me... :p 18:23:36 anything else here? 18:23:42 we haven't talked about audio 18:23:54 the VU meters sucked about as much as I expected :P 18:23:59 *nod* 18:24:02 should you info or todo things like start playback at a certain timestamp? 18:24:13 it may make sense to have a closer look at voctogui's VU meters, and clone them 18:24:32 #info the VU meters were not accurate 18:24:36 audio mixing started kinda rough but the preset scene feature + auto switchover on recording end got rid of most of these issues 18:24:53 I was hoping to get a chance to look at them during the conf, but ran out of time 18:24:58 it's still possible to do entirely auto audio mixing 18:25:02 based on A+B 18:25:37 tumbleweed: I'm sure someone will want to PiP a recording and talk over it at some point :P 18:25:40 #agreed starting a recording from a specific point would be helpful 18:27:06 I don't see anybody leaping up and down saying they want audio that follows video 18:27:16 (although there was some of that before and during the conference) 18:27:43 what does "audio that follows video" mean? as in, they are synced? 18:27:50 the way it is implemented currently gives the director the option to have audio follow video - just use full screen solo 18:27:57 as in, if you are displaying a video source, its audio will be unmuted 18:28:02 (ah nm I'm with you now) 18:28:14 paddatrapper: yeah, but an annoyingly large number of our directors never used that 18:28:24 they'd use A, B, layout buttons instead 18:28:33 and then have to have somebody unmute over their shoulder 18:28:34 is that a training issue or something to fix in Voctoweb? 18:28:44 maybe make it the default and let someone untick it if they want to do something fancy 18:28:47 maybe a bit of both? 18:28:55 the preset scene feature + auto switchover on recording end got rid of most of these issues 18:28:57 any of our historical directors will be used to the A+B buttons 18:29:02 and not used to having to deal with audio 18:29:10 yeah that is true 18:29:39 I was thinking before the conf that I'd do some sort of basic + advanced mode 18:29:43 but never got there 18:29:52 Perhaps focusing on the presets will fix this and if people need something else they use the advanced mode 18:29:56 e.g. you start with fullscreen solo buttons, and if you enable advanced it says "Here be dragons" 18:30:09 yeah imho advanced + sane defaults should be fine 18:30:20 :) 18:30:50 shall we move on? 18:30:50 I'm happy to take a look at that 18:30:54 #agreed default presets and an advanced mode should be fine 18:31:07 paddatrapper: happy to help get you started on that 18:31:07 #topic Playback 18:31:13 #undo 18:31:13 Removing item from minutes: 18:31:23 #topic DC20 Review - Playback 18:31:26 what's this about? playback of prerecorded videos? 18:31:30 got to be consistent :) 18:31:34 :P 18:31:43 move on? 18:31:45 highvoltage: yes, though I think it was covered in the previous topic 18:31:48 indeed 18:31:51 unless we want to talk about ingesting 18:31:57 or audio compression etc. 18:31:59 it was fortunately boring 18:32:18 I think we should prbably add a section for SReview and do it there? 18:32:38 could do 18:32:48 ah, I thought we had one already 18:32:53 although I think sreview wants to drop some of this responsibility (or do things very differently) 18:33:13 Ok, then we can talk about it now 18:33:23 pre-recorded videos were mostly good 18:33:36 review is an issue, but that's a content team action 18:33:40 Normalisation is a very good idea, but we ran into issues with our pipeline's expectations 18:33:56 mainly around audio 18:34:06 (as in, when we got a video with realy bad audio where it was tought to hear what the person said) 18:34:10 highvoltage: I suspect there's a technical aspect to review that we need to take 18:34:22 content were out of their depth on technical requirements for uploaded videos 18:34:33 look at the 8k audio sampling rate videos that got uploaded 18:34:38 I suppose there are some low-tech solutions to this too 18:34:48 did we ever find out what was recording at 8k sample rate? 18:34:52 like uploading the videos to a private peertube channel 18:34:54 olasd: pitivi 18:34:59 wtaf 18:35:03 #info content were out of their depth on technical requirements for uploaded videos 18:35:10 not sure why, but both of those came from people editing in pitivi 18:35:24 we could easily have automated checks on upload 18:35:29 I can't imagine that being a pitivi default!? 18:35:29 it's probable that it came from the first source they dropped in their timeline 18:35:43 Probably 18:35:43 that usually sets up the project parameters 18:36:25 this could be dealt with by doing automated rejections on ingest 18:36:33 rather than just trying to reencode everything 18:36:57 a mix of both would work - reject obviously bad and then reencode 18:36:58 I think the content team reviewers probably also needed a checklist 18:37:10 paddatrapper: yep 18:37:48 I tried to create such a checklist in one of the lead up meetings 18:38:03 #info a mix of automated rejections on ingest and re-encode the successful submissions would help ensure consistency 18:38:05 don't have the logs at hand, but I recall being shot down because the team knew what they were doing 18:38:35 Looking at the result, a checklist would be helpful 18:39:00 and a more explicit review pipeline 18:39:38 and probably more time for review 18:39:42 so many videos came on the last day or two 18:40:02 I don't know if giving people more time will help 18:40:04 I don't think we'll be able to improve /a lot/ on that 18:40:08 :) 18:40:22 yeah, I doubt we can get people to move faster 18:40:40 but it's safe to say we weren't keeping up 18:40:42 well we can close uploads; but even last-minute pre-recordings seemed to work well, in the end 18:40:47 still, we can better equip the content team, and should 18:41:05 I think one confusion here was that it wasn't clear which team's responsibility this was 18:41:09 I think our best bet is a systematic way of reviewing that doesn't requre the review to watch the entire talk and automated rejections 18:41:16 I thought this was speaker assistance 18:41:23 I don't know who was actually doing this (if anybody) 18:41:52 it all happened so quick that there was never a meeting to draw those lines and discuss who does what 18:42:12 I think urbec did some, but not sure what his review consisted of 18:42:43 when we first started discussing DC20 online we thought of it as "mostly a video team thing" 18:43:13 but our usual DebConf teams did get involved, I think we had at least /some/ responsibility to tell people what we expected from them, especially since this was all new and different 18:43:28 #info there was confusion about who should have been reviewing pre-recorded talks 18:43:33 again, I think we did ok with the time we had available and can do better next time 18:43:55 paddatrapper: automated rejection won't get things like very poor mics though 18:44:18 I still think it's a good idea to have someone review the talk manually 18:44:22 maybe we should require an external mic (as in, no laptop mics) 18:44:27 pollo: no, but it will get things like 8k audio or 144p video 18:44:27 pollo: it's step one 18:44:29 how many poor mics were noticed during review, notified, and actually fixed? 18:44:35 paddatrapper: lol 18:44:37 pollo: definitely need manual review too 18:44:41 1, none fixed :) 18:44:45 olasd: right, no time to actually do that 18:45:05 that seems like something to deal with in a speake racceptance email 2 months in advance 18:45:12 go buy a mic now, claim the expense 18:45:19 your talk has been accepted! please enter your address to receive your "proper presenter care package" 18:45:30 nice! 18:45:51 * gwolf lurks 18:46:03 Dear speaker, your last talk sounded so bad that, we decided to send you this mic. Please keep it, it's on the house, really. Now also use it. 18:46:06 Yes, many people still seem to think laptop microphons are decent-quality 18:46:42 in some cases they are 18:46:52 #info speakers need time to correct their talk if there are issues found in review 18:46:58 macbooks aren't terrible (if you're not typing on them) for example 18:47:02 tumbleweed: Odds are not on their side, though 18:47:18 This sounds like something for #-content or #-team maybe? 18:47:19 tumbleweed: macbooks are also not very popular in our demography 18:47:23 yeah 18:47:30 sadly thinkpad sound systems are truly awful 18:47:45 and those are quite popular in our demographic 18:48:02 it appears that we have thoroughly exhausted this topic. 18:48:05 anything else on this topic? 18:48:12 highvoltage: heh yeah 18:48:22 #topic DC20 Review - Loop 18:48:37 I think I can safely say that Loopy Loop was very successful 18:48:41 ok I'll try to be quick on this one (I'll only talk about it for an hour or so) 18:48:47 well done highvoltage 18:48:48 heh 18:48:52 I wrote a blog about it here /mehttps://jonathancarter.org/2020/08/30/the-metamorphosis-of-loopy-loop/ 18:48:55 thanks :) 18:49:03 the loop was great, but it involved a not very sustainable (i.e. crazy) amount of work 18:49:05 it was nice, my only fear would be that it looked like a lot of manual work 18:49:23 and have started working on the next iteration of it. there's a lot of ideas for improvements 18:49:42 it was a lot of manual work. very managable, I wouldn't want to do it like that again. 18:50:08 #info the loop looked great, but was a lot of manual work 18:50:26 towards the end of the DebConf I found that all the scenes and elements, and the sequences in advanced scene switcher is contained in a single .json file in that scene collection 18:50:33 #info highvoltage is gathering ideas for improvements 18:50:34 having the backup loop was convenient 18:50:35 I'd imagine this is somewhat autotomateable 18:50:51 unfortunately, changing the .json file doesn't change it live in OBS 18:51:00 and probably a task that volunteers could help with (editing incoming submissions) 18:51:08 but, the new OBS in testing also comes with a scripting host that supports Python and Lua 18:51:14 \o/ 18:51:17 so I think we should use that one next 18:51:34 OBS also has an API that I haven't tried out yet and will also try from there 18:51:48 would it make sense to have people send their snippets via peertube using a hashtag or something? 18:51:58 to automate the collection a bit 18:52:06 and even failing all of the above, the Advanced Scene Switched let's you control it by writing to arb files, so there's all kinds of ways and avenues available to drive it 18:52:11 olasd: prone to abuse 18:52:24 pollo: I didn't say that we should automatically put everything on the loop 18:52:30 (duh) 18:53:01 olasd: in this case, I postprocessed every video manually, not sure we'd do it again, but using the video as they provided as-is might not always be the solution 18:53:34 I'd also do things like the shoutout cards in OBS rather than encoding them in, which might be nice if we chain 5 shoutouts in a thread 18:53:37 #info OBS has a json config file for a profile, API and scripting host 18:54:08 and I want to add a whole bunch of other types of content to it, like talk promos/announcements (like on https://peertube.debian.social/videos/watch/64a8624e-1e57-4213-ba37-c72015294b36) 18:54:19 and postcards and a whole bunch of other things 18:55:01 (I was actually just joking about talking about it for an hour but it seems like I'm a roll so will stop myself for now, can give more details at another stage) 18:55:09 highvoltage: sure, just feels to me like 1/ having peertube do the basic transcode; 2/ only having to set a start/end time for playback; 3/ automating the cards in obs instead of in the snippet would cut out a bunch of the manual work 18:55:26 (not all of it, but some of it) 18:55:41 yep. 18:56:10 (nothing more on my end 18:56:17 Anything else? 18:56:23 I just want loopy for all events, so I want it sustainable) 18:56:30 +1 18:56:31 ack 18:56:44 wouter said that he'd like it for FOSDEM too 18:56:46 but... 18:56:58 I do think there's a chance here for volunteers 18:57:02 we haven't figured out how to make it for 2 tracks yet so... fosdem /o\ 18:57:08 this seems like it's high-profile enough that people would want to be involved 18:57:09 (way out of my league for this) 18:57:12 and not that high-skilled 18:57:25 +1 18:57:27 just need to be able to cut some video in an editor, boost audio, etc. 18:58:02 #info post-processing loop snippets is possibly a good avenue for volunteers 18:58:08 #topic DC20 Review - Grabber 18:58:15 yeah, could make a kdenlive (and probably some other video editing sofware if there's interest) tutorials that shows the specific stuff used to edit these clips 18:58:48 I would highly recomend pointing new people at Shotcut 18:59:13 so, grabber 18:59:17 everyone hated the VNC 18:59:22 there were some access reliability issues with VNC 18:59:24 but almost every talk used it 18:59:29 but especially highvoltage hated VNC 18:59:33 but once you got in it worked okay 18:59:40 I think? 18:59:40 #info VNC was difficult to use, but grabber was used a lot 18:59:56 seems we missed some training issues there 19:00:03 how to not bring up the firefox menu when it's fullscreen 19:00:12 I found myself explaining that to somebody on sunday 19:00:24 olasd: it worked for me 3 times in a row, and then it didn't 11 times in a row, and then it worked again a few times in a row. I ended up sifting through all my config files and deleteing every possible reference to VNC and I *think* it's better now 19:00:49 I would just reconnect until it worked 19:00:53 and/or kill the vnc server 19:00:56 I couldn't ever make xtigervncviewer work under wayland 19:01:04 it connected, but the display never refreshed 19:01:12 even though I could see my actions in voctoweb 19:01:15 that happened sometimes under X11 19:01:26 yeah, but it happened everytime in xwayland 19:01:27 :D 19:01:28 we may need to develop a remote-control-of-pad thing that we can drive from a browser 19:01:30 maybe half the time 19:01:44 and just avoid VNC completely 19:01:47 perhaps looking into a spice server might be nice for another time where we need remote desktop access? 19:01:55 we tried 19:01:57 it suuuuuucked 19:02:07 paddatrapper: +1 on remote controlling a pad potentially 19:02:12 awh pity 19:02:25 people did use the pad differently to what I expected 19:02:34 I was assuming questions would be asked on IRC 19:02:47 RDP then? (I think xrdp also relies on X at least on the other side, but at least it's efficient) 19:02:48 and the talkmeister would collate & summarise in thepad 19:03:03 highvoltage: I don't think efficiency was the problem 19:03:03 tumbleweed: yeah, people just ended up cutting out the middle-talkmeister 19:03:07 this seemed like a bug 19:03:13 which worked great, actually 19:03:22 yeah just like with the loop, we had no idea how people was actually going to use all this stuff until it happened 19:03:24 and some non-talkmeisters took on that collation & organisation role 19:03:37 #info potentially look into controlling the displayed section of the pad remotely to avoid needing VNC 19:03:50 no matter the stack, it helps when there are people around to pick up the slack 19:03:51 yeah I tried spice, no go 19:03:56 (you know it's true because it rhymes) 19:04:31 anything else on the grabber? 19:04:51 would we have been better off with talkmeisters sharing their own browser window? 19:04:55 (in jitsi) 19:05:05 I guess many wouldn't have had machines capable of it 19:05:08 the grabber was *crisp* 19:05:12 as a speaker I would say -1 19:05:13 I think we'll run into issues with video quality and readability 19:05:18 getting that through jitsi? ew. 19:05:55 OK, let's move on 19:05:56 keeping an eye on everything turned out to be so chaotic that I appreciated having someone who drove the etherpad and helped take care of a bunch of related things 19:06:11 highvoltage: yeah 19:06:20 #topic DC20 Review - Streaming 19:06:27 The RTMP streams worked well 19:06:32 except when they died 19:06:37 the low latency was very helpful 19:06:41 tumbleweed: yes, except then 19:06:44 kicking the nginxes in the mornings helped 19:06:45 they only died for me when people were restarting things afaict 19:07:02 I had some issues, but reconnecting fixed it 19:07:04 what sort of things were people restarting? 19:07:06 also the lower-quality streams didn't seem to die as often as the higher-quality ones 19:07:11 olasd: maybe that needs to be cron'd :) 19:07:26 but, yeah, the rtmp mirrors were very sensitive to (what I suppose were) network glitches between hosts 19:07:48 that seems like something that colud be fixed with monitoring + automated fixing 19:07:53 tumbleweed: I don't think people restarted things much 19:07:55 and yes 19:08:00 olasd: right, that was my point 19:08:07 yeah, I know 19:08:14 there were breakages that I couldn't attribute to any restarting 19:08:14 just driving it further 19:08:15 #info the RTMP streams were very sensitive to network glitches between hosts 19:08:31 I think nginx-rtmp has all the proper knobs to do the monitoring, we just need to Do It™ 19:08:41 #info the issues could potentially be fixed with monitoring and automated fixing 19:08:45