18:00:52 <paddatrapper> #startmeeting
18:00:52 <SSA> Meeting started Thu Jul  9 18:00:52 2020 UTC.  The chair is paddatrapper. Information about MeetBot at https://wiki.debian.org/MeetBot.
18:00:52 <SSA> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:03 <paddatrapper> #topic Roll call
18:01:08 <pollo> 0/
18:01:08 <tumbleweed> hi
18:01:15 * olasd does a barrel roll (call)
18:01:23 <paddatrapper> Agenda: http://deb.li/oNCD
18:02:36 <paddatrapper> #topic Actions from last meeting
18:03:24 <tumbleweed> #link http://meetbot.debian.net/debconf-video/2020/debconf-video.2020-07-02-17.58.html
18:03:37 <wouter> o/
18:03:39 <paddatrapper> tumbleweed: thanks, was struggling to find it
18:04:03 <wouter> um, what happened to meetbot?
18:04:11 <paddatrapper> nattie and I haven't done the presenter docs yet
18:04:11 <pollo> deaded for now
18:04:19 <wouter> mmkay
18:04:43 <pollo> I've started working on the voctoweb ansible role: https://salsa.debian.org/debconf-video-team/ansible/-/merge_requests/205
18:04:57 <pollo> I should be able to have something I think is mergeable today
18:05:04 <tumbleweed> cool
18:05:08 <paddatrapper> #action nattie to edit and compile presenter advice to video-team docs
18:05:12 <paddatrapper> #action paddatrapper to edit and compile presenter advice to video-team docs
18:05:31 <paddatrapper> #info pollo working on ansible voctoweb role
18:05:35 <wouter> paddatrapper: fyi, you can also say "#action foo and bar to xyz", and it shows up as an action for both ;-)
18:05:44 <paddatrapper> wouter: TIL thanks!
18:05:52 <tumbleweed> eww php
18:05:57 <pollo> yup
18:06:02 <pollo> and it's not pretty php either
18:06:03 <paddatrapper> #action paddatrapper to setup a Jitsi VM and add to ansible
18:06:17 <olasd> considering the code it'd take all of 10 minutes to re-do it in a sensible language
18:06:37 <tumbleweed> yeah, definitely room for improvement there
18:06:47 <tumbleweed> but working is the first important step
18:06:52 <pollo> :)
18:06:54 <pollo> agreed
18:06:55 <paddatrapper> olasd: have you had a chance to work on reducing the stream delay?
18:06:55 <wouter> well, it works, I don't think we need to reimplement everything first? ;)
18:07:10 <olasd> paddatrapper: as I said last time I'll work on that during the sprint
18:07:14 <olasd> so, no
18:07:19 <paddatrapper> ah right, yes
18:07:40 <paddatrapper> #action olasd to try minimize stream delay during the sprint
18:07:56 <tumbleweed> I poked at OBS, and got it working
18:08:04 <tumbleweed> I haven't worked on the geoip things this week
18:08:04 <olasd> (well technically I guess the sprint started, I merged a pollo MR:P)
18:08:10 <pollo> hehe
18:08:11 <paddatrapper> #info tumbleweed managed to get OBS working
18:08:38 <paddatrapper> #action tumbleweed to find a solution to the geoip issue
18:08:54 <paddatrapper> pollo: did you look at the audio sync, or was that also sprint?
18:09:00 <pollo> nope
18:09:08 <tumbleweed> I also experimented a little more with android + OBS locally, and got some pretty low-latency results (under 1s)
18:09:15 <paddatrapper> #action olasd to add a list of available recordings to voctoweb
18:09:27 <paddatrapper> tumbleweed: android and OBS?
18:09:34 <tumbleweed> paddatrapper: android camera into OBS
18:09:41 <paddatrapper> #action pollo to test audio sync
18:09:42 <paddatrapper> tumbleweed: ah
18:10:26 <tumbleweed> lowest latency setup I've found is droidcam's mjpeg http stream. It puts a timestamp on the top of the video (I think to encourage you to buy the paid version), but one could overlay something else over that
18:10:53 <tumbleweed> and I didn't realise, but OBS can import the srt streams directly, making larix+OBS better than I'd thought before
18:11:01 <tumbleweed> anyway, enough about that :)
18:11:16 <paddatrapper> #info lowest latency setup tumbleweed found is droidcam's mjpeg http stream, but includes timestamp in the video
18:11:25 <paddatrapper> ooh that is cool
18:11:32 <paddatrapper> #action wouter to work on review for prerecorded talks
18:11:43 <wouter> I actually did look at that
18:11:57 <paddatrapper> wouter: ah awesome
18:12:06 <wouter> I think the best we can do is have Q&A and prerecorded things be separate events in SReview
18:12:19 <wouter> then we can inject the prerecorded talks without review, and transcode them as is
18:12:37 <wouter> and review the Q&A which we then release as a separate file
18:13:07 <paddatrapper> and potentially combine downstream of SReview?
18:13:13 <wouter> anything else will require me to figure out a way to either stitch together two files that will not stitch together very well, or implement a full nonlinear editor
18:13:22 <wouter> which I don't think is a good idea
18:13:27 <wouter> eh, perhaps, we could do that too
18:13:31 <wouter> but I don't think we need to
18:13:54 <pollo> I think we should, IMO the Q&A is part of the talk
18:13:58 <paddatrapper> For YouTube and PeerTube it would be useful to have just one
18:14:02 <paddatrapper> file
18:14:07 <pollo> and that
18:14:11 <ivodd> I don't think it's essential to have it as 1 file
18:14:16 <wouter> okay, I'll see how to make that possible then
18:14:18 <nattie> +1 on Q&A being part of the talk
18:14:21 <nattie> context is important
18:14:22 <olasd> is there more action items to review or should we move on to more specific topics?
18:14:50 <wouter> although the easiest way to accomplish that is to just include the prerecorded as part of the review
18:15:02 <paddatrapper> #topic Blocked salsa issues
18:15:02 <wouter> i.e., don't inject prerecorded stuff, just review as it was broadcast
18:15:09 <paddatrapper> olasd: nope :)
18:15:38 <wouter> (well, I did have the VM usage action item, but I forgot that was even assigned to me, so didn't do much)
18:15:39 <paddatrapper> I think we covered the issues in the previous topic, anything in particular to raise here?
18:15:50 <pollo> not from me
18:16:00 <paddatrapper> wouter: we did have the discussion with zigo after the meeting last week though
18:16:35 <wouter> yes
18:16:43 <paddatrapper> #topic Video stack
18:16:47 <wouter> what I'm saying is that I missed it was for me and I'm not sure we discussed everything
18:16:56 <paddatrapper> ah I see
18:17:15 <paddatrapper> \o/
18:17:18 <tumbleweed> wb
18:17:22 <ivodd> somebody set up vocto, and I played with it a little, and was able to make it hang
18:17:32 <wouter> hang, in what way?
18:17:38 <ivodd> it seems vocto is very peculiar about the exact format of the video coming in
18:17:38 <tumbleweed> and, how?
18:17:51 <wouter> oh, that's not so good
18:17:52 <ivodd> the video I tried had different interleaving
18:17:53 <tumbleweed> are you talking about the interlaced example we spoke about here?
18:18:04 <wouter> oh right, you did say that
18:18:07 <tumbleweed> that just needed to be deinterlaced before injection
18:18:09 <ivodd> and after that, that specific input didn't work anymore, until voctocore was restarted
18:18:17 <ivodd> tumbleweed: that's not the point
18:18:20 <wouter> we could theoretically fix that by re-encoding everything
18:18:24 <tumbleweed> ivodd: no, it is the point
18:18:24 <ivodd> there might be other setting we don't think about
18:18:29 <tumbleweed> voctomix expects consistent inputs
18:18:37 <tumbleweed> if we build a system that gives it that, it's happy
18:18:39 <wouter> I have a few scripts that use the SReview::Video API to ensure that things are encoded the same way, re-encoding if necessary
18:18:39 <ivodd> but as wouter said, I think we need to re-encode everyting beforehand
18:18:57 <ivodd> wouter: the video's I tried were all encoded with sreview in the past, so no consistency there either
18:19:01 <wouter> I can set up something that will allow people to upload things and that re-encodes them ready for broadcast
18:19:02 <tumbleweed> not necessarily
18:19:16 <wouter> ivodd: only because I have changed the output profiles a few times over the years
18:19:21 <wouter> ivodd: that won't be the case for this system
18:19:26 <pollo> what would be the impact on video quality of reenconding everything?
18:19:34 <tumbleweed> the problems you'd have to fix are identical for injecting or re-encoding?
18:19:40 <tumbleweed> s/?/./
18:19:41 <wouter> pollo: depends on the encoder settings
18:20:00 <pollo> well, that's my main worry
18:20:03 <wouter> pollo: if we set them high enough (which I intend to do) then there shouldn't be much loss
18:20:04 <ivodd> it would be good to have an automated way to test the re-encoded result as well, obviously
18:20:12 <tumbleweed> pollo: I'd expect negligable loss
18:20:18 <paddatrapper> We definitely ran into issues at SotM for not encoding
18:20:30 <paddatrapper> re-encoding I mean
18:20:34 <wouter> I'll try to whip up something simple this weekend
18:20:35 <ivodd> paddatrapper: what did you use for SotM? vocto?
18:20:41 <paddatrapper> ivodd: OBS
18:20:47 <tumbleweed> why did OBS care?
18:20:50 <CarlFK> if you rely on the file to be in a format, then you can't change at the last minute
18:20:52 <wouter> where a speaker can upload a talk, and then gets an email when it's re-encoded to our settings
18:20:57 <ivodd> wouter: we actually also want review of the incoming talks, so maybe just use review :)
18:21:01 <wouter> so they can test if everything looks fine
18:21:02 <paddatrapper> tumbleweed: multiple resoltions, formats, etc
18:21:04 <wouter> or that :)
18:21:11 <CarlFK> if fix the format on the fly, you get it right every time
18:21:14 <pollo> ivodd: that's not a bad idea!
18:21:15 <ivodd> wouter: s/review/sreview
18:21:15 <tumbleweed> we definitely shouldn't support multiple resolutions
18:21:24 <paddatrapper> +1
18:21:32 <ivodd> CarlFK: no
18:21:35 <olasd> tumbleweed: I agree the problems are the same between ingest and re-encode, but re-encoding everything to have a consistent input format to feed voctomix means we have consistent resource usage during the live event
18:21:42 <ivodd> CarlFK: you have to make sure you don't forget any setting that might be wrong
18:21:55 <tumbleweed> olasd: true. But at the same time, playback is so cheap, that doesn't worry me at all
18:22:01 <olasd> tumbleweed: is it though?
18:22:14 <tumbleweed> in my experience, yes
18:22:20 <olasd> my experience has been very different
18:22:22 <ivodd> anyway, as I was saying (before everyone started making suggestions):
18:22:33 <CarlFK> ivodd: ingest.py asks the server for the current settings, so no human needs to figure it out
18:22:35 <wouter> it depends on the file size and the codec, but H.264 is easy on today's hardware
18:22:43 <wouter> (where "easy" means "cheap")
18:22:44 <tumbleweed> CarlFK: except ingest doesn't detect interlaced video
18:22:47 <tumbleweed> that's a bug, that we should fix
18:22:50 <ivodd> - vocto is difficult about input format, and we need to get it EXACTLY right, or we need to restart voctocore
18:23:01 <ivodd> - inputs coming and going don't seem to be a problem
18:23:14 <tumbleweed> ivodd: I can't imagine anything except interlacing causing that problem
18:23:15 <wouter> CarlFK: also, H.264 has many many fiddly settings that can cause issues if you don't re-encode
18:23:19 * wouter found that out the hard way
18:23:21 <ivodd> CarlFK: I used ingest.py, and it doesn't work correctly in all cases
18:23:24 <tumbleweed> ivodd: it wouldn't even accept video in other resolutions
18:23:32 <CarlFK> tumbleweed: I think I got it - want me to file an issue, or do you have details handy?
18:23:39 <CarlFK> ivodd: so I hear ;)
18:23:39 <tumbleweed> ivodd: and there aren't that many other free parameters
18:23:54 <tumbleweed> CarlFK: interlaced video
18:24:01 <ivodd> tumbleweed: I have no idea, I'm just reporting what I found out
18:24:08 <wouter> this is why I think re-encoding everything to *exactly* the same settings is the best issue
18:24:12 <wouter> er, best solution I mean
18:24:20 <wouter> then there won't be any problems
18:24:33 <CarlFK> wouter: unless the settings change, then ka-boom
18:24:36 <olasd> then there will be a single set of problems
18:24:41 <wouter> well, don't do that then :)
18:24:49 <ivodd> wouter: that has the advantage that we can publish the result (without Q&A) immediately after the talk
18:24:52 <tumbleweed> wouter: assuming your re-encoding stack deinterlaces, in that case
18:24:53 <wouter> olasd: true, yeah
18:25:02 <wouter> tumbleweed: I can make it do that if necessary
18:25:03 <tumbleweed> a typical re-encoding would use the same interlacing/progressive on output, as input
18:25:10 <pollo> we're likely to re-encode the videos we get from presenters anyway before releasing them right?
18:25:20 <tumbleweed> I don't think that's necessary
18:25:22 <wouter> ffmpeg has options to force re-encoding, so that's not an issue
18:25:24 <tumbleweed> but other people here seem to
18:25:33 <tumbleweed> so, whatever :)
18:25:45 <paddatrapper> SotM feedback - pre-recorded talks and Jitsi Q&A worked well. We published a pad per session for questions, that worked better than filtering questions from IRC in my opinion
18:26:00 <ivodd> paddatrapper: that's a different topic
18:26:09 <wouter> tumbleweed: if Q&A and prerecorded video is not encoded at the same settings, one of them will need to be re-encoded or you can't combine them
18:26:20 <paddatrapper> ivodd: we don't have an agenda point for yet
18:26:21 <tumbleweed> wouter: that's not what we're talking about, at all
18:26:25 <paddatrapper> s/yet/it/
18:26:29 <pollo> well, from all of this, I think it's more prudent to have presenter videos go by Sreviews, have them reviewed by a Human that can check for obvious mistakes, and re-encode them for release & playback
18:26:43 <ivodd> paddatrapper: i'm not saying it's a bad topic :)
18:27:53 <wouter> tumbleweed: I thought it was, but meh, doesn't matter that much
18:27:57 <olasd> that doesn't prevent us/CarlFK from hardening ingest against different interlacing settings too
18:27:57 <tumbleweed> pollo: sure, sounds reasonable. And I guess that makes the later combination wouter spoke of trivial
18:28:41 <wouter> #action wouter to look at setting up SReview for pre-recorded talks
18:29:04 <wouter> (although I'm not sure I can actually do that...)
18:29:19 <paddatrapper> #action wouter to look at setting up SReview for pre-recorded talks
18:29:32 <paddatrapper> no idea if you can, but makes sure :P
18:29:34 <tumbleweed> can't do the work? or can't tell the bot?
18:29:42 <wouter> the latter :)
18:29:52 <tumbleweed> so, high level video stack
18:30:06 <tumbleweed> it sounds like no real arguments against voctomix at this point
18:30:26 <olasd> have we tried feeding jibri output to voctomix yet?
18:30:28 <tumbleweed> OBS is still there as a fallback, but we're assuming vocto is the way to go
18:30:34 <paddatrapper> olasd: not yet
18:30:42 <tumbleweed> we need to get the jitsi up
18:30:50 <pollo> I don't think anyone tested the audio sync either
18:30:54 <wouter> I think we should test that ASAP, before deciding on whether or not to OBS?
18:30:55 <paddatrapper> Yeah I plan on getting that up this week
18:30:56 <pollo> or maybe ivodd did?
18:31:16 <pollo> we do have a sprint tomorrow+sat+sun :)
18:31:22 <ivodd> pollo: I was searching for a video where it would be easy to see the audio sync when I hit the lockup issue
18:31:31 <ivodd> so, no :(
18:31:38 <pollo> good to know, thanks
18:31:46 <ivodd> pollo: BTW it was your talk that caused the lockup :)
18:31:51 <ivodd> (and olasd's)
18:31:52 <olasd> IME audio sync was always a resource exhaustion issue on the voctocore; if we run into that without a voctogui, we should worry :P
18:32:12 <ivodd> pollo: I did test switching audio sources, and that just works as expected
18:32:21 <tumbleweed> yeah, me too
18:32:37 <tumbleweed> what will be different is switching audio sources. Not something we've ever needed before
18:32:50 <olasd> yeah, audio source switching has always worked; we just disable the GUI to do that because we don't need it
18:32:52 <olasd> but it works
18:33:17 <ivodd> also, the latency on the preview stream from here was acceptable
18:33:31 <tumbleweed> from here, too
18:33:33 <olasd> (doesn't mean we shouldn't make sure it works within our setup, just that it shouldn't be an issue in general)
18:33:36 <ivodd> I didn't try the giu remotely
18:33:42 * tumbleweed did
18:33:50 <tumbleweed> but I only had 2 sources
18:34:09 <tumbleweed> if we have a few more (IRC, jitsi, gobby), it'll certainly add up
18:34:36 <paddatrapper> I think we should probably stress test with more at some point
18:35:04 <tumbleweed> that's this weekend :)
18:35:08 <tumbleweed> shall we move on?
18:35:13 <ivodd> yes, but we should also try to make sure we don't have too many sources
18:35:17 <ivodd> but we can move on
18:35:19 <paddatrapper> #topic Streaming setup
18:36:02 <paddatrapper> Don't think anything here is changing from last week?
18:36:12 <olasd> so my plan for the weekend is to set up rtmp push and see where that gets us wrt. latency
18:36:27 <olasd> (instead of pulling hls over https)
18:36:39 <olasd> (instead or in addition of, actually)
18:38:51 <wouter> anything to add to that?
18:39:16 <tumbleweed> and I'll finish the geoip rework
18:39:33 <olasd> I guess not; we can move on
18:39:35 <paddatrapper> #topic Advice/training for directors
18:39:48 <ivodd> paddatrapper: I added your previous topic to the agenda before that
18:39:58 <ivodd> because we need to know how we do thing before we give advice to directors :)
18:40:22 <paddatrapper> I'll work on this after we have finalised the stack, so probably after the sprint
18:40:51 <paddatrapper> #topic How to run Q&A
18:41:24 <paddatrapper> SotM found direct access to pads for each session was quite nice
18:41:35 <ivodd> paddatrapper: can you explain the setup you had?
18:41:48 <paddatrapper> Easier than filtering from IRC and allowed answers to be recorded there too
18:42:01 <ivodd> the talkmeister/director and the presenter in jitsi and everyone else on the pad?
18:42:32 <ivodd> of was the pad managed by specific people
18:42:36 <ivodd> s/of/or
18:42:42 <pollo> I think the main problem we have is how to capture the questions to get them into voctomix
18:42:47 <paddatrapper> ivodd: We had a etherpad for each talk which was linked from the talk detail page on the website (needs to be better published)
18:43:00 <ivodd> paddatrapper: and everyone could add questions to it?
18:43:03 <pollo> the jank solution I worked on involves running IRC in the framebuffer and capturing that
18:43:05 <paddatrapper> They were then read out by the talk meister in the Jitsi session
18:43:08 <paddatrapper> ivodd: yes
18:43:14 <ivodd> ok
18:43:21 <olasd> what happens at CCC (when there's lots of questions in irc): the signal angel (person responsible to relay questions) sends the URL of a pad to the audience; the audience and the signal angel work together on collating questions and ordering them by priority / interest; at Q&A time, the signal angel asks the questions in order
18:43:35 <tumbleweed> olasd: that sounds like the way to go
18:43:46 <paddatrapper> In the Jitsi session (1 per talk), there was the director, mixer (OBS output), presenter and talk meister
18:43:48 <tumbleweed> and the pad can be a source in vocto / jitsi too
18:44:15 <paddatrapper> the OBS output was there for allowing the talk meister and presenter to follow along with the pre-recorded talk
18:44:29 <CarlFK> tumbleweed: what renders the pad text into video?
18:44:32 <pollo> tumbleweed: by capture a browser?
18:44:40 <tumbleweed> yeah
18:44:57 <ivodd> paddatrapper: why did you need a director, a 'mixer' and a talk meister?
18:45:01 <pollo> jibri seems to be doing that and is pretty heavy
18:45:13 <paddatrapper> ivodd: the mixer is the OBS output feed from the pre-recorded talk
18:45:34 <ivodd> oh, that's not a separate person, but a separate source in jitsi?
18:45:40 <tumbleweed> pollo: it'll be slightly better, without playing videos in the browser. But CPU usage is hardly a critical concern for us, here
18:45:45 <paddatrapper> the director is the one controlling Jibri and talk meister interacts with presenter
18:46:08 <paddatrapper> ivodd: yeah, but not intended for going out on air, rather as feedback for people in the Jitsi room
18:46:32 <ivodd> paddatrapper: ok, I was thinking about how many people we would need per talk, but you were talking about sth else :)
18:46:46 <paddatrapper> ivodd: ah, yeah we had 2 - director and talk meister
18:46:56 <ivodd> paddatrapper: and that worked ok?
18:47:13 <paddatrapper> wait 3 - technical assistant for helping the presenter before
18:47:39 <paddatrapper> ivodd: 3 worked very well, but then again we didn't have any presenter technical issues that I know of
18:47:48 <ivodd> ok, good to know
18:47:59 <ivodd> and did you have any live events/bofs? (apart from Q&A after a talk)
18:48:20 <paddatrapper> One talk that eventually was live because the pre-record just wouldn't play
18:48:37 <paddatrapper> welcome, closing and 1 quiz thing
18:48:47 <paddatrapper> they worked well with enough pre-testing
18:48:52 <pollo> for bofs people usually use gobby, if we can't get a web client for that, we'll need to tell people to use $approved_webpad
18:49:21 <pollo> err, I guess we can capture the gobby X11 window...
18:49:22 <olasd> why would we need a web client?
18:50:09 <wouter> we don't, I think pollo was confused :)
18:50:40 <pollo> but setting those up will surely involve some clickedy-clicks via a VNC
18:50:58 <wouter> yeah, but that's not a problem, is it?
18:51:07 <pollo> it means director needs to have a VNC access
18:51:08 <olasd> worst case, just have one of the presenters share gobby over jitsi/bri
18:51:27 <tumbleweed> pollo: seems reasonable to me
18:51:31 <pollo> if the talkmeister could do that, I think it would be better
18:51:55 <paddatrapper> Given good enough internet connection, that would be good
18:52:24 <olasd> you don't need a //good// internet connection to scroll down a static window full of text
18:52:36 <paddatrapper> olasd: but you need it to share it over Jitsi
18:52:46 <olasd> (if we do it static over vnc)
18:52:48 <tumbleweed> if you're using a jitsi, and the talkmeister has a good connection, they can do this themselves
18:53:05 <olasd> right
18:53:06 <tumbleweed> for live mixing in vocto, a capture from a local gobby / IRC client would probably be much better quality
18:53:20 <pollo> and we don't need to have a whole VNC setup (and possibly a VNC web interface) for directors
18:53:26 <paddatrapper> would also ensure consistent look and feel
18:53:44 <paddatrapper> ^ a local capture in vocto
18:53:48 <ivodd> we should test things like that this weekend and see what works well
18:53:51 <olasd> is anyone planning on trying the vnc stuff?
18:54:06 <tumbleweed> yeah
18:54:10 <olasd> who? :P
18:54:18 <highvoltage> (I'm up for playing/experimenting/testing over the weekend)
18:54:21 <tumbleweed> I'll poke at it
18:54:26 <paddatrapper> #agreed test sharing Gobby though Jitsi and capturing on voctomix during the sprint
18:54:37 <pollo> if possible, using SPICE would be interesting
18:54:41 <paddatrapper> #action tumbleweed to poke and VNC on vocto machine
18:55:00 <tumbleweed> pollo: I've never used spice
18:55:20 <tumbleweed> whatever we use needs to have a display bitmap to grab and stream, server-side
18:55:23 <highvoltage> it's much more efficient than vnc (closer to rdp)
18:55:24 <wouter> tumbleweed: spice is more bandwidth-efficient
18:55:38 <tumbleweed> rigth, but RDP is not the right solution for this problem
18:55:43 <tumbleweed> not sure where spice fits on that spectrum
18:55:44 <wouter> no, but spice can be :)
18:56:01 <highvoltage> yeah but... *sigh*
18:56:04 <wouter> it's used a lot in the qemu/kvm space
18:56:24 <olasd> tumbleweed: there's the capture side (fed through to vocto), and the control side (which the talkmeister uses?)
18:56:36 <olasd> spice/rdp/vnc are the control side
18:56:36 <tumbleweed> err
18:56:49 <tumbleweed> yes
18:56:59 <tumbleweed> if those are clearly separate then we're good
18:57:01 <pollo> and there is https://packages.debian.org/buster/spice-html5 if we need to fallback to a webinterface
18:57:09 <tumbleweed> if the capture has to capture from the talkmeister's machine, we screwed up
18:57:19 <highvoltage> tumbleweed: spice is like vnc but more clever in sending only bits that changed, and afaik if you do things like drag a window (or scroll in a webpage) it knows how to shift similar bits around better
18:57:21 <olasd> tumbleweed: yeah, no, that wouldn't make sense
18:58:16 <paddatrapper> Anything else here?
18:58:25 <wouter> spice also has features to send along alternate streams, which qemu uses to piggyback a USB channel -- not that that matters here ofc
18:58:36 <olasd> (afaict we need 1/ a remote x11 server to run gobby / etherpad / whatnot; 2/ x11grab that through to vocto; 3/ have spice/rdp/vnc for the director to control that)
18:58:56 <wouter> yeah, sounds about right
18:59:10 <pollo> I think that can all live on the voctomix VM
18:59:26 <olasd> maybe
18:59:39 <olasd> it needs setting up, testing
18:59:43 <tumbleweed> given the massive VMs we have a tthe moment, it could
18:59:47 <tumbleweed> but I don't like that
18:59:58 <tumbleweed> I just mailed zigo to ask for more credits for smaller VMs
19:00:06 <tumbleweed> don't want to run out of credits on the weekend
19:00:06 <pollo> +1
19:00:20 <pollo> but I think he'll need to ask permission for that
19:00:31 <tumbleweed> hopefully he can tomorrow
19:00:33 <pollo> that's why he wanted to stay under 4
19:00:39 <tumbleweed> I asked on IRC a few days ago, but didn't get a response
19:01:25 <tumbleweed> oh, I did. I missed that
19:01:26 <pollo> worst case scenario we can spin up DO droplets?
19:01:40 <tumbleweed> yeah, or use personal accounts elsewhere
19:01:50 <tumbleweed> highvoltage seemed amenable to refunding reasonable expenses there
19:02:32 <paddatrapper> #action Advice/training for presenters
19:02:41 <paddatrapper> nattie and I will work on this tomorrow
19:02:47 <highvoltage> (and even more amenable to setting it up long-term so that video team can spin up/down whenever needed and it gets billed to TO automatically)
19:02:48 <olasd> #undo; #topic
19:02:58 <paddatrapper> #undo
19:02:58 <SSA> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x7f8c04784c10>
19:03:03 <paddatrapper> urg thanks
19:03:09 <wouter> :)
19:03:12 <paddatrapper> #topic Advice/training for presenters
19:03:16 <wouter> I was confused what that was supposed to mean :)
19:03:25 <paddatrapper> too many actions this meeting
19:03:29 <paddatrapper> nattie and I will work on this tomorrow
19:03:34 <nattie> yep
19:03:36 <paddatrapper> #topic Stats on talk submissions
19:03:56 <tumbleweed> the submission deadline has passed now
19:04:14 <tumbleweed> #link https://debconf20.debconf.org/talks/statistics/
19:04:20 <olasd> nice
19:04:34 <pollo> will there be language tracks?
19:04:47 <tumbleweed> doesn't look like any happened
19:05:03 <ivodd> tumbleweed: do we know how many are bof-type events?
19:05:42 <tumbleweed> 20 BoFs
19:05:54 <wouter> that's quite a bit, I expected less of them
19:06:03 <ivodd> indeed
19:06:13 <tumbleweed> 2 sprints (both pollo :P)
19:06:21 <pollo> muahha
19:06:26 <pollo> won't be videoed though
19:06:32 <olasd> rejected!
19:06:55 <pollo> it might be a good idea to have a way to switch jitsi from 720p to 480p for BoFs
19:07:11 <pollo> especially for large ones
19:07:37 <ivodd> with that many bofs, we'll need to look into the details of the bof setup and do test runs
19:07:59 <tumbleweed> pollo: yeah
19:08:14 <wouter> maybe we should ask people who want to join in a bof to let themselves known, so we can see whether much planning is necessary?
19:08:19 <paddatrapper> pollo: I seem to recall that requires a config change and a Jitsi restart... could be wrong though
19:08:25 <paddatrapper> but will have a look
19:08:28 <pollo> paddatrapper: that's about it yes
19:08:30 <wouter> during MDCO we had ~20 people in a room, which worked quite well
19:08:47 <wouter> if we don't expect any bofs with more people (which seems likely) then there's not really an issue
19:08:52 <pollo> paddatrapper: but it would be nice not to have to do it manually (and to forget it's at 480p when it shouldn't be)
19:08:57 <paddatrapper> #action paddatrapper to investigate easy switching of Jitsi from 720p to 480p for large bofs
19:09:03 <paddatrapper> pollo: +1
19:09:54 <pollo> wouter: large jitsi rooms are hard on bandwidth and CPU for users
19:09:57 <highvoltage> pollo: it's 480p now bit it wasn't for mdco
19:10:09 <pollo> it's not really a problem on the server side
19:10:14 <tumbleweed> lazy answer could be 2 jitsis :P
19:10:17 <wouter> pollo: hm, okay, that could make a difference
19:10:24 <wouter> tumbleweed: and then have a link between them? ;)
19:10:36 <tumbleweed> no, send people to the right one for the event
19:10:38 <highvoltage> (480p is actually ok for most of the webcam quality we end up getting, screen shares seem to be displayed at higher resolutions)
19:10:38 <paddatrapper> well each room requires a link anyway
19:10:52 <paddatrapper> #topic Any other business
19:10:55 <paddatrapper> #undo
19:10:55 <SSA> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x7f8c04784b90>
19:11:04 <paddatrapper> Itchy finger :P
19:11:12 <wouter> heh :)
19:11:13 <paddatrapper> Anything else here?
19:12:23 <paddatrapper> #topic Any other business
19:12:42 <wouter> so, the FOSDEM orga team is looking at what to do for FOSDEM 2021
19:12:56 <wouter> is there any interest in cooperating with them?
19:13:12 <highvoltage> tell them good luck? :p
19:13:15 <wouter> heh :)
19:13:32 <olasd> bold of you to assume 2021 will happen
19:13:36 <ivodd> wouter: what exactly are you asking?
19:13:43 <olasd> (and yes I mean the year, not the FOSDEM edition)
19:13:51 <paddatrapper> heh
19:14:02 <highvoltage> I'm sure 2021 will happen whether there will be humans around to observe it or not
19:14:03 <pollo> olasd: all hail Cthulhu destroyer of worlds
19:14:04 <wouter> ivodd: basically, share our expertise and maybe help out?
19:14:19 <wouter> for starters, do we have a writeup of our lessons learned from the mdco etc?
19:14:22 <paddatrapper> are they looking at potentially remote?
19:14:26 <wouter> yes
19:14:35 <wouter> amongst other things
19:14:35 <paddatrapper> wouter: we do, I'll find the link
19:14:39 <paddatrapper> I'd be interested - useful to develop a semi-common set of tools
19:14:51 <wouter> yeah, that's the point
19:14:58 <pollo> they already use vocto + sreview
19:15:03 <wouter> yup
19:15:04 <pollo> the only new var here is jtisi
19:15:15 <wouter> well, and scale
19:15:27 <pollo> scale can simply mean more servers
19:15:28 <wouter> FOSDEM is... "slightly" larger than Debconf, in terms of audience ;)
19:15:30 <wouter> sure
19:15:32 <paddatrapper> wouter: https://storm.debian.net/shared/e2upoEOfvRsvPt9rQO9KfNKC0ld55_OT4evgJ8AZJMb
19:15:35 <wouter> but you want things to work well
19:15:41 <highvoltage> scaling wise it seems like they just need more streaming servers and a better method to collect/rank questions
19:15:57 <paddatrapper> I seem to recall more generic notes too, but not sure where they ended up
19:16:02 <highvoltage> (the latter we might want at some point too)
19:16:04 <ivodd> I think managing a setup like ours for that many rooms might not be easy
19:16:25 <ivodd> at least we'll know how well it goes for 1 room :)
19:16:46 <paddatrapper> I guess it depends on how brittle it turns out to be
19:17:20 <wouter> okay. FOSDEM is still at the "what shall we do" stage, it's probably too early for them to decide on going online-only
19:17:31 <wouter> but getting info on how things fare for DebConf might be good, I guess
19:17:41 <wouter> I just thought I'd bring it up, in case anyone is interested in helping out, etc
19:17:55 <ivodd> wouter: the fosdem people can join our channel and follow along :)
19:18:08 <wouter> yeah, I'll bring that up too, but hey
19:18:28 <tumbleweed> ivodd: yeah, I'd imagine their stack will end up quite different to ours
19:18:44 <wouter> tumbleweed: well, it is kinda sorta similar already though
19:19:26 <tumbleweed> I mean, jumping between recorded talks and jitsi
19:19:33 <tumbleweed> having tens of jitsis
19:19:48 <wouter> oh, hm
19:20:00 <tumbleweed> well, tens of rooms
19:20:06 <tumbleweed> with tens of jibris
19:20:12 <wouter> I'm thinking they might end up with a jitsi per devroom or some such, or maybe a structured way of generating room names
19:20:21 <wouter> if they end up going the jitsi way
19:20:37 <pollo> BBB can scale better irrc
19:20:43 <wouter> what's that?
19:20:47 <paddatrapper> yeah we generated jibri room names from talk names - just base64 encoded to avoid invalid characters
19:20:55 <wouter> right
19:21:00 <pollo> anyway, I think we can get to the next point and chat about FOSDEM later?
19:21:02 <paddatrapper> wouter: BigBlueButton
19:21:11 <wouter> oh, right, think I heard about that
19:21:21 <paddatrapper> A bunch of painful java that somehow works pretty reliably
19:21:27 <wouter> pollo: sure, I didn't mean to have an hour-long chat about it right now ;)
19:21:35 <paddatrapper> #topic Upcoming meetings
19:21:45 <paddatrapper> Meeting next week Thursday 18:00 UTC?
19:21:51 <pollo> wfm
19:21:55 <wouter> think so?
19:22:17 <paddatrapper> #agreed Next meeting - 16 July 2020 @ 18:00 UTC
19:22:38 <paddatrapper> #info Sprint Friday 10 July - Sunday 12 July
19:22:46 <paddatrapper> Don't forget about the sprint tomorrow :)
19:23:12 <pollo> I've successfully shifted my schedule
19:23:18 <pollo> can't sleep after 8am anymore :p
19:23:31 <paddatrapper> #info can tentatively aim for some video test runs on the weekend of 17-19 July (will finalise dates after the sprint)
19:23:50 <paddatrapper> #endmeeting