18:00:12 #startmeeting 18:00:12 Meeting started Sat Aug 22 18:00:12 2020 UTC. The chair is tumbleweed. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:12 All guests should now be reporters 18:00:18 ginggs: you should be able to see it now 18:00:19 #link http://deb.li/oNCD Agenda 18:00:30 hi 18:00:33 0/ 18:00:36 say hi if you're here for the meeting 18:00:41 \o 18:00:45 hi if you're here for the meeting 18:00:52 hi o/ 18:00:53 (yeah it's been a while :P) 18:00:59 :) 18:01:03 o/ 18:01:27 hello 18:01:54 #topic Video Stack - Jitsi 18:02:16 seems to work? 18:02:16 So, since the last meetnig there were some reports that jitsi was not showing everybody's video 18:02:20 I think that's normal behavior 18:02:31 although apparently meet.jit.si doesn't seem to be as sensitive to it 18:03:04 what do you mean by "not showing everybody's video" ? 18:03:05 are there any details on what exactly is going wrong with it? 18:03:08 yeah, same question 18:03:09 yeah, that 18:03:12 :) 18:03:27 18:04 < tumbleweed> I did some hacking on skinning the jitsi last nigth 18:03:27 18:04 < tumbleweed> there's probably more we can do 18:03:27 18:04 < tumbleweed> I think jiust the house logo would probably work better than the current logo 18:03:53 * nattie waves belatedly 18:03:54 yeah, there was even a recording 18:04:00 see #debian-social from a few days ago 18:04:03 I can dig out logs 18:04:55 http://fam-tille.de/tmp/barbara_andreas_jitsi/frames_06_00_video_stopped.tgz was the recording 18:05:08 is it something we can fix before the conference, and/or is it a major issue that would result in problems? If not I'd think we can just ignore it... 18:05:14 there may be a config switch in meet that sets the threshold for low bandwidth mode - where inactive participants have their video turned off for a local user 18:05:16 yeah, let's ignore and move on 18:05:33 It only affects the local user and not the stream (from what I understand) 18:05:42 I'm sure we'll get all sorts of werid bug reports in the next days 18:05:45 paddatrapper: yes, if you can find that and tune it a bit that might make sense, but other than that... 18:06:01 tumbleweed: or the past few ones, too ;) 18:06:12 #topic Video Stack - Voctoweb 18:06:25 olasd: my changes to the fullscreen button may have negated some of the need for presets 18:06:34 tumbleweed: cool 18:06:42 although they could be useful for PinP 18:07:04 auth is done, and seems people aren't complaining 18:07:05 The only trick people need to be aware of is setting grabber full screen using the Fullscreen Solo will mute Jitsi 18:07:27 paddatrapper: would you like a Fullscreen button too 18:07:31 and then Fullscreen Solo can be red 18:07:47 the way paddatrapper explained it during training was pretty okay I'd say 18:07:52 tumbleweed: maybe, using the A button also works, but not as intuitive 18:08:15 paddatrapper: otoh, having two "fullscreen" buttons might be even less intuitive 18:08:19 +1 18:08:27 could rename the second one to just Solo 18:08:39 But that probably makes more sense to somebody who knows an audio desk 18:08:43 than a random video volunteer 18:08:47 or add a "changes audio!" 18:08:53 tumbleweed: since we've been training people on the current interface though, I'd be wary of changing it too radically at this point 18:09:02 Maybe change the colour of the current and leave it as is? 18:09:08 wouter: yeah, that's why I pushed those throguh last night 18:09:13 hmm, so there's no sound when using the "loop" button ? 18:09:16 Generally people know red = dangerous 18:09:22 pollo: yeah 18:09:26 but it isn't dangerous 18:09:33 paddatrapper: except in China, where green = dangerous... 18:09:34 Red is also the color of B source, though 18:09:39 would have associated red with off here 18:09:49 I used blue because A source 18:09:54 true. Then leave it to be consistent with training 18:10:14 red is "record" 18:10:23 if source == 'grabber': disable_audio_switching() :P 18:10:41 I've tried to avoid source-specific hacks like that, but we totally can 18:11:01 anyway, let's keep moving 18:11:06 tumbleweed: yeah, but I think it wouldn't help 18:11:10 #topic Vide Stack - Playback 18:11:23 +o 18:11:25 Haven't poked at seeking any more 18:11:31 or wouter's API yet 18:11:49 if that doesn't happen, we'll just manually copy over the day's videos 18:11:50 we now have a script for playback fallback though 18:11:51 tumbleweed: I don't think seeking is critical, it shouldn't change anyway? 18:11:53 that was always the fallback plan 18:12:15 so are tomorrow's videos ready? 18:12:21 videoteam@voctomix1:~$ videoteam-recordings-playback -h 18:12:31 yes, all videos have been successfully transcoded now 18:12:44 so are tomorrow's videos ready to be played back on voctomix1? 18:12:48 I just went over all 42 submitted videos and hit the "play" button in the SReview interface 18:12:51 ok 18:12:52 they all work 18:12:53 cool 18:13:00 so, we need to copy them over 18:13:06 I'll talk to wouter about that after the meeting 18:13:10 sure 18:13:18 #topic Video Stack - Loop Generation 18:13:30 The loop is currently bouncing through the streaming backend to voctomix 18:13:32 and it's a bit dodgy 18:13:34 e.g. right now 18:13:51 * tumbleweed restarts it 18:14:05 when reading it through rtmp it's just fine, so clearly an ingest issue 18:14:16 yeah 18:15:11 that's videoteam-ingest-0.service if anyone wants to hack o nit 18:15:23 cron a restart of ingest in the middle of each talk? :P 18:15:30 * olasd hides 18:15:39 olasd: it's actually not too terrible an idea 18:16:13 maybe have voctoweb do it when you switch away from the loop ;) 18:16:53 and yes, the backup loop has no audio 18:17:03 I haven't investigated whether this is by design or I screwed up 18:17:36 #topic Video Stack - Grabber 18:17:40 probably nothing to say here, as usual? 18:17:46 highvoltage isn't here though, right? 18:17:54 doesn't seem to be 18:18:11 he's out having supper I believe 18:18:12 #topic Video Stack - SReview 18:18:34 yeah, there were more bugs than I'd hoped for, but things seem to be worked out now 18:18:48 videos are already stored in per-day directories 18:19:07 We still don't have title screens for recordings 18:19:16 so you just need to copy over the right directory; if all you need from the metadata is the date, then you don't need the metadata 18:19:21 yeah, I was about to say that 18:19:43 cool, yeah, that was always the easy way to get pre-recorded talks 18:19:47 it's not crucial just yet, and worst case I'm married to a graphic designer, but she's already said she doesn't have time 18:20:09 so, for an online conference, I think getting talks out ASAP is important 18:20:15 we should try to get something done today 18:20:23 so they can start releasing tomorrow 18:20:28 I also have a script that syncs the states of the three talks, and it seems to work for Q&A 18:20:34 er, three events I mean 18:20:55 if you go to the overview page and you go to the "Q&A" event, you'll see that the talks that don't have any recording are marked as "ignored" there 18:21:07 the idea being that for a live talk you must review through the "normal" event 18:21:16 and for a prerecorded talk you need to only review the Q&A event 18:21:21 and for others you'll combine the pre-recording with the Q&A? 18:21:32 SReview will, yes 18:21:45 the review would just review the recording to get out the Q&A 18:22:05 and then the prerecording and the Q&A will be injected into the "main" event and be chucked out as a single video 18:22:47 I haven't yet had time to test that out in detail, I intend to do that by manually running the transcode job for the first prerecorded event... 18:23:01 we'll see whether it has any issues (I sure hope not) 18:23:15 other than that I'm ready 18:23:18 OK 18:23:28 Anyone want to take an action to hack together some title screens? 18:23:55 I'll do it tomorrow if nobody else pitches up anything by then 18:24:03 I assume if someone creates an ugly draft, other people will suggest improvements :P 18:24:07 (but I wouldn't complain if someone does...) 18:24:09 heh, true :) 18:24:11 I'll see if my brother is able to tonight 18:24:46 FWIW: https://salsa.debian.org/debconf-team/public/data/dc20-online/-/issues/11 18:25:26 #info wouter will create a title screen tomorrow if nobody else has yet 18:25:34 #info paddatrapper will ask his brother if he can do a title screen 18:25:41 #topic Video Stack - Streaming 18:26:17 so, the yt fallback has been implemented 18:26:21 yeah 18:26:24 so, on that 18:26:47 if nginx goes down for too long (like this morning when I was making the dump directory bigger) 18:26:50 it'll stop 18:26:59 Are we streaming to yt by default or just falling back to it in case of trouble? 18:27:04 and it won't create a new stream unless you have streaming control panel open when nginx starts 18:27:20 so... it may break and require a nginx restart to fix 18:27:39 tumbleweed: IIRC, youtube assumes that once the stream stops that's the end of it and you need to create a new live stream, right? 18:27:43 pollo: we're pushing to it so that we have it as an option 18:28:03 wouter: yes. And I can't seem to do that if the video is already being sent 18:28:10 thus the nginx restart 18:28:22 at OSW.co.za I did live streams to youtube straight from vocto 18:28:29 wouldn't that be an option? 18:29:03 yes it would 18:29:14 but also unnecessary? 18:29:48 sure; I'm just thinking it cuts out moving parts between vocto and youtube so there's less space for something to go wrong 18:29:50 tumbleweed: if we need to publish the yt stream url something is on fire and there will be a video team member around, so I don't think having to do an nginx restart is much of a problem 18:29:55 Have we load tested yet? If not I can ping #debian-devel after the meeting 18:30:02 olasd: right 18:30:10 paddatrapper: you had an action to test? 18:30:20 who has access to the youtube control panel beyond tumbleweed though? 18:30:24 I do 18:30:36 okay, good 18:30:54 wouter: I think it'll survive short outages (i.e. restarts) just not long ones 18:31:12 pollo: So, then, yes there is the question 18:31:13 tumbleweed: hasn't happened yet 18:31:17 The week ran away with me 18:31:22 should we make the YT stream public? 18:31:34 It seems reasonable to me - if it's useful to our audience 18:31:38 what problem would that solve? 18:31:38 and it probably brings an audience 18:31:55 tumbleweed: sure -- I was just thinking that if you have things go through nginx, then nginx becomes a SPOF, which would be nice to avoid, but it's not critical and if you think it would not improve matters then I'm that's fine 18:32:04 the downside is that it's not being looked after as carefully as anything else 18:32:28 I think it's dangerous, as people will expect it to work 18:32:30 tumbleweed: meh 18:32:34 also the youtube interface doesn't have any of the interaction options 18:32:35 And most of us don't have access to it 18:32:46 that can be fixed 18:33:00 wouter: neither does mpv 18:33:09 I'm okay with it being a backup option, but I'd suggest not publishing it except in case of real problems 18:33:12 I don't have a google account :) 18:33:24 that can be fixed (:P) 18:33:25 And I can't create one since my phone is voip 18:34:15 can't you bypass giving them a phone number? I've always been able to... 18:34:31 Nope 18:34:33 not that you must have a google account though (in fact...) 18:34:36 anyway; I think the answer is "no" on making the stream public 18:34:38 can we step back from pollo's anti-googleness and talk about the question at hand 18:34:42 yeah, seems the consensus is no 18:34:43 sorry 18:34:44 for now at least? 18:35:19 #topic Video Stack - Etherpad 18:35:26 nobody seems to be complaning atm, so I guess it works 18:35:31 heh :) 18:35:38 it does mean people need salsa accounts, though 18:35:40 yeah, it seemed to work during paddatrapper's training 18:36:21 I guess nobody has actually tested it in the grabber yet 18:36:29 because I haven't heard complaints about needing to be logged into salsa from the grabber 18:36:39 the trick there is to use the public URL for the pad which doesn't require auth 18:36:54 Yeah I don't think anyone has tried changing the grabber pad yet 18:37:31 or we should log into salsa from a test user 18:37:33 I guess there's no way to avoid the auth altogether? 18:37:53 +1 for test user 18:37:54 we decided to have auth to be able to deal with abuse 18:38:01 * tumbleweed has a test user we can use 18:38:20 fair enough 18:38:27 or we could make a dedicated user and have its credentials on the readme 18:38:28 I'm just a little worried that there are other flows that are 18:38:35 going to come up in every event and nobody has tested 18:38:37 (the rabber readme) 18:38:40 grabber* 18:39:13 I think a test user is probably a good idea, yes 18:39:20 I have one, I'll log it in 18:39:25 keep it logged in, and add the credentials to the readme just in case 18:39:38 #topic Video Stack - Embed in the Website 18:39:39 .oO(doesn't pollito have a salsa account?) 18:39:57 So, highvoltage was reporting some HLS issues this morning 18:40:19 looks like if the stream glitches (eg nginx restart) we get 503 / 404s that don't have CORS headers 18:40:28 and the browser caches this fact for the lifetime of the page 18:40:39 so, we should fix that 18:41:08 There's also things video.js does to try to avoid reusing those bad streams (see the discussion before the meeting) 18:41:17 didn't seem like there was anything we need to tweak there, though 18:41:28 tumbleweed: the trick seems to add "always" at the end of the add_header directive in the nginx config 18:41:37 according to stackoverflow :P 18:41:45 olasd: can I action you? 18:41:54 yeah 18:42:04 #action olasd to add CORS headers to streaming frontend errors 18:42:23 #topic Advice/training for directors talkmeisters 18:42:27 We had training today \o/ 18:42:34 so many training 18:42:36 The two sessions went well 18:42:37 yeah, and it seemed to go well 18:42:41 One more to go 18:42:43 and aside from auth, nobody seems to be complaining about anything 18:42:53 Yeah 18:42:58 I should have attended, seeing how I'm pretty much the lone volunteer for tomorrow morning ;p 18:43:04 We should probably hold training during the conf too 18:43:10 paddatrapper: definitely 18:43:13 yeah, I was wondering about that 18:43:15 we need more volunteers 18:43:39 has anyone sent a "videoteam needs you" video to loopy? 18:44:04 I'll probably be around tomorrow morning too, in case you need me 18:44:22 tumbleweed: action md 18:44:24 Me 18:44:38 #action pollo to send a "videoteam needs you" video to loopy 18:44:51 #topic Advice/training for presenters 18:45:00 speaker test calls are happening 18:45:01 I see this has been happening 18:45:07 any jitsi issues? 18:45:28 there was the occasional thing where people would say they were joined but we couldn't see them 18:45:34 but that would sort itself out when they reloaded 18:46:01 so... arrive early for your talk so issues can be resolved 18:46:41 I guess that's that 18:46:52 #topic Actions from last meeting 18:46:57 pollo wrote the playback fallback 18:47:00 I think "arrive early" is a good idea regardless 18:47:08 indeed 18:47:20 #topic AoB 18:47:33 how does the playback fallback work? 18:47:45 -h apparently 18:48:18 we need more volunteers for tomorrow morning; I'm currently alone for the first two talks :P 18:48:29 olasd: like I said, I can be around too 18:48:33 /usr/local/bin/videoteam-recordings-playback -i path/to/videofile -p HH:MM:SS 18:48:35 sorry, can't help there :) 18:48:37 olasd: does that include the opening session? 18:48:41 nattie: yes 18:48:50 well, that doesn't really need a talkmeister as such 18:48:52 and it might be a good idea if the first few talks are videoteam members so that we can fix issues if they appear? 18:48:58 yeah 18:50:50 i can probably also be around and talkmeister if nobody else signs up for those 18:51:09 Anything before this Debian med bof is too early for me 18:52:33 tomorrow I'll be away from computers, but then I could be more active (and better internet for volunteering) 18:52:56 I think that's it for AoB? 18:53:20 #topic Next Meeting 18:53:47 should we do something after the last talk tomorrow evening to evaluate how things are going, or would that be too soon? 18:53:54 The DC20 team is going to do potential meetings in the 16:45 break every day 18:54:07 we can do ours later than that 18:54:13 I think that's a good idea regardless 18:54:24 wouter: I'm not sticking around until 1:20 AM for a feedback meeting :P 18:54:47 although... maybe 18:54:50 that same 16:45 break could be a good time to meet 18:54:56 although we'd want to not clash 18:55:10 tumbleweed: we could also do the 18:00 UTC one 18:55:11 there's enough overlap between videoteam and general orga that clashing should be avoidable 18:55:17 er, 18:45 UTC 18:55:17 talks start at 18:00 18:55:29 ah, damn 18:55:32 looking at the wrong times, sorry 18:55:42 I suspect the team meeting will be short and we can meet after it? 18:55:47 yes, I think so 18:55:52 but it's hard to set a specific time 18:55:56 maybe 17:00 ? 18:56:01 alternatively, the 20:45 UTC slot could work too 18:56:07 (for me, at least) 18:56:11 bit late, but doale 18:56:14 +b 18:56:33 Shall we play it by ear tomorrow 18:56:37 yes 18:56:39 Try for 17:00 18:56:41 yeah, think so 18:56:44 Reassess if necessary 18:56:49 +1 18:56:50 I think we might want to discuss feedback from the orga meeting during our meetings anyway 18:56:53 #agreed let's attempt to meet at 17:00 UTC daily 18:56:55 right 18:56:56 yeah 18:56:58 so having them close together would be sensible 18:57:14 Let's call this done then 18:57:16 #endmeeting