18:00:03 <paddatrapper> #startmeeting
18:00:03 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:06 <tumbleweed> yay
18:00:20 <paddatrapper> #topic Roll call
18:00:22 <olasd> (there's this thing called #chair :P)
18:00:24 <olasd> o/
18:00:29 <nattie> yo yo in da house
18:00:30 <pollo> \0
18:00:38 <paddatrapper> Agenda: http://deb.li/oNCD
18:00:54 <paddatrapper> nattie: yo-yos also work outside in the garden :P
18:01:02 <tumbleweed> o/
18:01:04 <highvoltage> o/
18:01:38 <paddatrapper> #topic DC20 Review
18:02:07 <highvoltage> DC20 worked out pretty well, for a start
18:02:07 <nt1036> :)
18:02:21 <paddatrapper> Feedback pad - https://storm.debian.net/shared/c_q9vqo2cciXrJ-iI7AdI5pzavfF0HwRQqjC3yELotz
18:02:32 <paddatrapper> Yeah I think it worked out very well
18:02:41 <olasd> it was nice to be using etherpad for a while 0:-)
18:02:48 * olasd ducks
18:03:01 <nattie> wait, there's another question on the etherpad!
18:03:02 <highvoltage> storm will be faster soon™
18:03:05 <terceiro> I'm in work meeting, but will keep an eye to see if there's anything where my input is useful
18:03:34 <highvoltage> remember how worried everyone was each time I talked about adding OBS to the stack?
18:03:38 <highvoltage> times OBS crashed: 0
18:03:59 <paddatrapper> #topic DC20 Review - recordings status
18:04:02 <olasd> the vm it was running on was... quite overpowered ;)
18:04:10 <highvoltage> overpowered is good.
18:04:21 <paddatrapper> Do we know where the reviews are currently? Are there more to do?
18:04:38 <tumbleweed> I gave up trying to answer that question
18:04:49 <olasd> we've had reports of some talks missing, and of some talks being misnamed
18:04:58 <olasd> I have no idea what is in what state
18:05:03 <paddatrapper> #info Some talks missing from archive and some being misnamed
18:05:18 <olasd> I've seen some reviews happening for the Malayalam track earlier this week
18:05:20 <pollo> tumbleweed: have you started uploading to YT ?
18:05:26 <tumbleweed> well I did
18:05:33 <tumbleweed> but then some things got reencoded
18:05:42 <tumbleweed> and it was stated that everything was going to get reencoded
18:05:44 <highvoltage> oh interesting I thought that usually only happens once they're all finighe
18:05:48 <tumbleweed> so, shrug? nafc what's going on
18:05:49 <highvoltage> finished
18:06:04 <tumbleweed> highvoltage: normally, we'd try to get videos finished within a day or two of the talk
18:06:10 <paddatrapper> #info YT uploads pending resolution of current state
18:06:23 <paddatrapper> Ok, then not much else we can do here but wait for wouter
18:06:31 <paddatrapper> #topic DC20 Review - Jitsi
18:06:51 <paddatrapper> Having a seperate room for each talk seemed to work well for the most part
18:07:01 <paddatrapper> Directors kept forgetting to stop the stream at the end though
18:07:16 <tumbleweed> having extra jibris (and the 10 minute timeout) helped there
18:07:24 <highvoltage> *nod*
18:07:40 <olasd> the fact that live streaming doesn't end when everyone (who's not jibri) leaves the room is quite counterintuitive
18:07:47 <pollo> +1
18:08:01 <paddatrapper> #info extra jibris helped mitigate directors forgetting to stop the stream
18:08:01 <highvoltage> I... (hmm should I even mention this now)...
18:08:18 <highvoltage> am also looking at potentially replacing jibri with OBS :)
18:08:19 <paddatrapper> olasd: we should be able to set the timeout to a minute or so from the next Jibri release
18:08:25 <olasd> paddatrapper: definitely
18:08:34 <olasd> I mean, definitely we should do that
18:09:14 <paddatrapper> 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 <tumbleweed> highvoltage: still not convinced that's actually a step forward - don't see jibri itself as being problematic
18:09:25 <pollo> +1
18:09:29 <highvoltage> sorting out authentication for jitsi (and whatever streams it) is quite important too imho
18:09:46 <paddatrapper> +1
18:09:50 <pollo> i'm not so sure after all
18:09:58 <pollo> people will need to share the password
18:10:01 <highvoltage> tumbleweed, pollo: I know, I'm hoping you feel different once you see it working
18:10:02 <tumbleweed> auth wasn't really an issue at dc20
18:10:08 <pollo> how is it different from a URL?
18:10:20 <olasd> my main want for the jitsi side is being able to get the real-time stream in it
18:10:25 <highvoltage> pollo: URLs are much easier to leak, for one
18:10:29 <paddatrapper> people are more hesitant pasting passwords into IRC chats
18:10:52 <tumbleweed> olasd: yeah, wholesale replacement of jitsi with something tailor-made for conferences would be nice
18:11:07 <paddatrapper> 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 <tumbleweed> I assumed quiet bofs would just post the URL in IRC
18:11:27 <highvoltage> *nod*
18:12:27 <olasd> anything more to be added?
18:12:28 <highvoltage> 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 <paddatrapper> There is some re-architecting I want to look at for Billowconf, but hopefully that could serve some of these requirements
18:13:28 <paddatrapper> highvoltage: sure. The TL;DR is that it uses pure WebRTC with HTTP as the side-channel for client-server comms
18:13:44 <highvoltage> does it do any video mixing?
18:14:17 <paddatrapper> no. It is a SFU (selective forwarding unit), so clients receive the feeds they subscribe to
18:14:36 <highvoltage> kk no more questions for now
18:15:19 <paddatrapper> #agreed need to get real-time stream feed into Jitsi
18:15:55 <paddatrapper> #topic DC20 Review - Voctoweb
18:16:01 <tumbleweed> I think that comes with a bunch of complexity, but... :P
18:16:09 <tumbleweed> (I mean, avoiding feedback etc.)
18:16:21 <tumbleweed> I suspect that's best accomplished by not using jitsi
18:16:25 <highvoltage> (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 <olasd> (#undo maybe)
18:16:37 <highvoltage> (or hosted vlc)
18:16:38 <paddatrapper> #undo
18:16:38 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x108bd10>
18:16:41 <paddatrapper> olasd: yeah
18:16:44 <olasd> can we move on?
18:16:57 <tumbleweed> highvoltage: still, feedback risk
18:17:03 <highvoltage> yeah we can talk more about that topic later
18:17:07 <paddatrapper> what we did from SotM was a windowed projector from OBS captured into Jitsi
18:17:10 <tumbleweed> if the point is for the speakers to know when to start speaking
18:17:17 <tumbleweed> it can't really be playing in jitsi, without getting feedback
18:17:35 <paddatrapper> the projector only had the recorded talk source available to it, so no feedback
18:17:46 <tumbleweed> that makes more sense
18:17:56 <paddatrapper> #topic DC20 Review - Voctoweb
18:17:56 <pollo> directors gave a countdown
18:17:58 <pollo> worked well
18:18:17 <highvoltage> voctoweb was great, thanks tumbleweed!
18:18:20 <tumbleweed> I should follow-through on the rename now
18:18:28 <tumbleweed> and decide how much more time I want to spend on it... :P
18:18:33 <olasd> +1, voctoweb worked very well
18:18:45 <paddatrapper> #agreed VoctoWeb worked very well
18:18:51 <tumbleweed> playback started to get into the territory where it starts to feel easier to just replace voctocore entirely
18:18:57 <highvoltage> I am *so* glad we didn't have to VNC and use usual voctomix for this
18:19:12 <highvoltage> 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 <paddatrapper> highvoltage: definiteiyl. VNC with SotM was a nightmare
18:19:35 <olasd> tumbleweed: I wonder how much of it would be reusable with voc2mix
18:20:14 <tumbleweed> olasd: I haven't seen an overview of what's new in voc2mix
18:20:24 <olasd> neither
18:20:28 <tumbleweed> but architecturally ,it doesn't look like things have changed that much
18:20:53 <pollo> From our experience, I don't think seeking is needed
18:21:07 <tumbleweed> inter -> interpipe is the big change
18:21:10 <pollo> With the fallback script we can fix errors
18:21:17 <highvoltage> I think there was one time when a video was restarted
18:21:18 <olasd> did we ever use it?
18:21:25 <olasd> (the fallback script)
18:21:27 <pollo> Not that I'm aware of
18:21:30 <tumbleweed> neither
18:21:32 <highvoltage> might be nice to be able to specify a starting position for a video at the play menu
18:21:40 <tumbleweed> that would be fairly simple
18:21:44 <tumbleweed> it's the seeking during playback that's hard
18:21:51 <highvoltage> (in case it restarted say, at 30m, in this case it was just a minute or so so not a trainsmash)
18:22:13 <olasd> *nod*
18:22:18 <paddatrapper> I think allowing seeking provides more opportunity for things to go wrong that actual use
18:22:25 <olasd> +1
18:22:27 <tumbleweed> and seeking still seems doable, I just never found my bug
18:22:44 <olasd> "oops, scroll wheel focus wrong, just seeked through the talk"
18:22:49 <highvoltage> lol
18:23:11 <olasd> I've stopped counting how many times that has happened to me... :p
18:23:36 <paddatrapper> anything else here?
18:23:42 <tumbleweed> we haven't talked about audio
18:23:54 <tumbleweed> the VU meters sucked about as much as I expected :P
18:23:59 <olasd> *nod*
18:24:02 <highvoltage> should you info or todo things like start playback at a certain timestamp?
18:24:13 <tumbleweed> it may make sense to have a closer look at voctogui's VU meters, and clone them
18:24:32 <paddatrapper> #info the VU meters were not accurate
18:24:36 <olasd> 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 <paddatrapper> I was hoping to get a chance to look at them during the conf, but ran out of time
18:24:58 <tumbleweed> it's still possible to do entirely auto audio mixing
18:25:02 <tumbleweed> based on A+B
18:25:37 <olasd> tumbleweed: I'm sure someone will want to PiP a recording and talk over it at some point :P
18:25:40 <paddatrapper> #agreed starting a recording from a specific point would be helpful
18:27:06 <tumbleweed> I don't see anybody leaping up and down saying they want audio that follows video
18:27:16 <tumbleweed> (although there was some of that before and during the conference)
18:27:43 <highvoltage> what does "audio that follows video" mean? as in, they are synced?
18:27:50 <paddatrapper> the way it is implemented currently gives the director the option to have audio follow video - just use full screen solo
18:27:57 <tumbleweed> as in, if you are displaying a video source, its audio will be unmuted
18:28:02 <highvoltage> (ah nm I'm with you now)
18:28:14 <tumbleweed> paddatrapper: yeah, but an annoyingly large number of our directors never used that
18:28:24 <tumbleweed> they'd use A, B, layout buttons instead
18:28:33 <tumbleweed> and then have to have somebody unmute over their shoulder
18:28:34 <paddatrapper> is that a training issue or something to fix in Voctoweb?
18:28:44 <highvoltage> maybe make it the default and let someone untick it if they want to do something fancy
18:28:47 <tumbleweed> maybe a bit of both?
18:28:55 <olasd> the preset scene feature + auto switchover on recording end got rid of most of these issues
18:28:57 <tumbleweed> any of our historical directors will be used to the A+B buttons
18:29:02 <tumbleweed> and not used to having to deal with audio
18:29:10 <paddatrapper> yeah that is true
18:29:39 <tumbleweed> I was thinking before the conf that I'd do some sort of basic + advanced mode
18:29:43 <tumbleweed> but never got there
18:29:52 <paddatrapper> Perhaps focusing on the presets will fix this and if people need something else they use the advanced mode
18:29:56 <tumbleweed> e.g. you start with fullscreen solo buttons, and if you enable advanced it says "Here be dragons"
18:30:09 <highvoltage> yeah imho advanced + sane defaults should be fine
18:30:20 <highvoltage> :)
18:30:50 <tumbleweed> shall we move on?
18:30:50 <paddatrapper> I'm happy to take a look at that
18:30:54 <paddatrapper> #agreed default presets and an advanced mode should be fine
18:31:07 <tumbleweed> paddatrapper: happy to help get you started on that
18:31:07 <paddatrapper> #topic Playback
18:31:13 <paddatrapper> #undo
18:31:13 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x1375b10>
18:31:23 <paddatrapper> #topic DC20 Review - Playback
18:31:26 <highvoltage> what's this about? playback of prerecorded videos?
18:31:30 <paddatrapper> got to be consistent :)
18:31:34 <tumbleweed> :P
18:31:43 <tumbleweed> move on?
18:31:45 <paddatrapper> highvoltage: yes, though I think it was covered in the previous topic
18:31:48 <highvoltage> indeed
18:31:51 <tumbleweed> unless we want to talk about ingesting
18:31:57 <tumbleweed> or audio compression etc.
18:31:59 <highvoltage> it was fortunately boring
18:32:18 <paddatrapper> I think we should prbably add a section for SReview and do it there?
18:32:38 <tumbleweed> could do
18:32:48 <pollo> ah, I thought we had one already
18:32:53 <tumbleweed> although I think sreview wants to drop some of this responsibility (or do things very differently)
18:33:13 <paddatrapper> Ok, then we can talk about it now
18:33:23 <pollo> pre-recorded videos were mostly good
18:33:36 <highvoltage> review is an issue, but that's a content team action
18:33:40 <paddatrapper> Normalisation is a very good idea, but we ran into issues with our pipeline's expectations
18:33:56 <paddatrapper> mainly around audio
18:34:06 <highvoltage> (as in, when we got a video with realy bad audio where it was tought to hear what the person said)
18:34:10 <tumbleweed> highvoltage: I suspect there's a technical aspect to review that we need to take
18:34:22 <tumbleweed> content were out of their depth on technical requirements for uploaded videos
18:34:33 <tumbleweed> look at the 8k audio sampling rate videos that got uploaded
18:34:38 <highvoltage> I suppose there are some low-tech solutions to this too
18:34:48 <olasd> did we ever find out what was recording at 8k sample rate?
18:34:52 <highvoltage> like uploading the videos to a private peertube channel
18:34:54 <tumbleweed> olasd: pitivi
18:34:59 <olasd> wtaf
18:35:03 <paddatrapper> #info content were out of their depth on technical requirements for uploaded videos
18:35:10 <tumbleweed> not sure why, but both of those came from people editing in pitivi
18:35:24 <pollo> we could easily have automated checks on upload
18:35:29 <highvoltage> I can't imagine that being a pitivi default!?
18:35:29 <tumbleweed> it's probable that it came from the first source they dropped in their timeline
18:35:43 <paddatrapper> Probably
18:35:43 <tumbleweed> that usually sets up the project parameters
18:36:25 <tumbleweed> this could be dealt with by doing automated rejections on ingest
18:36:33 <tumbleweed> rather than just trying to reencode everything
18:36:57 <paddatrapper> a mix of both would work - reject obviously bad and then reencode
18:36:58 <tumbleweed> I think the content team reviewers probably also needed a checklist
18:37:10 <tumbleweed> paddatrapper: yep
18:37:48 <tumbleweed> I tried to create such a checklist in one of the lead up meetings
18:38:03 <paddatrapper> #info a mix of automated rejections on ingest and re-encode the successful submissions would help ensure consistency
18:38:05 <tumbleweed> don't have the logs at hand, but I recall being shot down because the team knew what they were doing
18:38:35 <paddatrapper> Looking at the result, a checklist would be helpful
18:39:00 <paddatrapper> and a more explicit review pipeline
18:39:38 <tumbleweed> and probably more time for review
18:39:42 <tumbleweed> so many videos came on the last day or two
18:40:02 <pollo> I don't know if giving people more time will help
18:40:04 <olasd> I don't think we'll be able to improve /a lot/ on that
18:40:08 <pollo> :)
18:40:22 <tumbleweed> yeah, I doubt we can get people to move faster
18:40:40 <tumbleweed> but it's safe to say we weren't keeping up
18:40:42 <olasd> well we can close uploads; but even last-minute pre-recordings seemed to work well, in the end
18:40:47 <highvoltage> still, we can better equip the content team, and should
18:41:05 <tumbleweed> I think one confusion here was that it wasn't clear which team's responsibility this was
18:41:09 <paddatrapper> 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 <tumbleweed> I thought this was speaker assistance
18:41:23 <tumbleweed> I don't know who was actually doing this (if anybody)
18:41:52 <highvoltage> it all happened so quick that there was never a meeting to draw those lines and discuss who does what
18:42:12 <paddatrapper> I think urbec did some, but not sure what his review consisted of
18:42:43 <highvoltage> when we first started discussing DC20 online we thought of it as "mostly a video team thing"
18:43:13 <highvoltage> 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 <paddatrapper> #info there was confusion about who should have been reviewing pre-recorded talks
18:43:33 <highvoltage> again, I think we did ok with the time we had available and can do better next time
18:43:55 <pollo> paddatrapper: automated rejection won't get things like very poor mics though
18:44:18 <pollo> I still think it's a good idea to have someone review the talk manually
18:44:22 <highvoltage> maybe we should require an external mic (as in, no laptop mics)
18:44:27 <paddatrapper> pollo: no, but it will get things like 8k audio or 144p video
18:44:27 <tumbleweed> pollo: it's step one
18:44:29 <olasd> how many poor mics were noticed during review, notified, and actually fixed?
18:44:35 <highvoltage> paddatrapper: lol
18:44:37 <paddatrapper> pollo: definitely need manual review too
18:44:41 <pollo> 1, none fixed :)
18:44:45 <tumbleweed> olasd: right, no time to actually do that
18:45:05 <tumbleweed> that seems like something to deal with in a speake racceptance email 2 months in advance
18:45:12 <tumbleweed> go buy a mic now, claim the expense
18:45:19 <olasd> your talk has been accepted! please enter your address to receive your "proper presenter care package"
18:45:30 <highvoltage> nice!
18:45:51 * gwolf lurks
18:46:03 <highvoltage> 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 <gwolf> Yes, many people still seem to think laptop microphons are decent-quality
18:46:42 <tumbleweed> in some cases they are
18:46:52 <paddatrapper> #info speakers need time to correct their talk if there are issues found in review
18:46:58 <tumbleweed> macbooks aren't terrible (if you're not typing on them) for example
18:47:02 <gwolf> tumbleweed: Odds are not on their side, though
18:47:18 <paddatrapper> This sounds like something for #-content or #-team maybe?
18:47:19 <gwolf> tumbleweed: macbooks are also not very popular in our demography
18:47:23 <tumbleweed> yeah
18:47:30 <tumbleweed> sadly thinkpad sound systems are truly awful
18:47:45 <highvoltage> and those are quite popular in our demographic
18:48:02 <highvoltage> it appears that we have thoroughly exhausted this topic.
18:48:05 <paddatrapper> anything else on this topic?
18:48:12 <paddatrapper> highvoltage: heh yeah
18:48:22 <paddatrapper> #topic DC20 Review - Loop
18:48:37 <paddatrapper> I think I can safely say that Loopy Loop was very successful
18:48:41 <highvoltage> ok I'll try to be quick on this one (I'll only talk about it for an hour or so)
18:48:47 <paddatrapper> well done highvoltage
18:48:48 <paddatrapper> heh
18:48:52 <highvoltage> I wrote a blog about it here /mehttps://jonathancarter.org/2020/08/30/the-metamorphosis-of-loopy-loop/
18:48:55 <highvoltage> thanks :)
18:49:03 <olasd> the loop was great, but it involved a not very sustainable (i.e. crazy) amount of work
18:49:05 <pollo> it was nice, my only fear would be that it looked like a lot of manual work
18:49:23 <highvoltage> and have started working on the next iteration of it. there's a lot of ideas for improvements
18:49:42 <highvoltage> it was a lot of manual work. very managable, I wouldn't want to do it like that again.
18:50:08 <paddatrapper> #info the loop looked great, but was a lot of manual work
18:50:26 <highvoltage> 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 <paddatrapper> #info highvoltage is gathering ideas for improvements
18:50:34 <pollo> having the backup loop was convenient
18:50:35 <tumbleweed> I'd imagine this is somewhat autotomateable
18:50:51 <highvoltage> unfortunately, changing the .json file doesn't change it live in OBS
18:51:00 <tumbleweed> and probably a task that volunteers could help with (editing incoming submissions)
18:51:08 <highvoltage> but, the new OBS in testing also comes with a scripting host that supports Python and Lua
18:51:14 <tumbleweed> \o/
18:51:17 <highvoltage> so I think we should use that one next
18:51:34 <highvoltage> OBS also has an API that I haven't tried out yet and will also try from there
18:51:48 <olasd> would it make sense to have people send their snippets via peertube using a hashtag or something?
18:51:58 <olasd> to automate the collection a bit
18:52:06 <highvoltage> 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 <pollo> olasd: prone to abuse
18:52:24 <olasd> pollo: I didn't say that we should automatically put everything on the loop
18:52:30 <olasd> (duh)
18:53:01 <highvoltage> 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 <highvoltage> 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 <paddatrapper> #info OBS has a json config file for a profile, API and scripting host
18:54:08 <highvoltage> 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 <highvoltage> and postcards and a whole bunch of other things
18:55:01 <highvoltage> (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 <olasd> 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 <olasd> (not all of it, but some of it)
18:55:41 <highvoltage> yep.
18:56:10 <olasd> (nothing more on my end
18:56:17 <paddatrapper> Anything else?
18:56:23 <olasd> I just want loopy for all events, so I want it sustainable)
18:56:30 <paddatrapper> +1
18:56:31 <highvoltage> ack
18:56:44 <highvoltage> wouter said that he'd like it for FOSDEM too
18:56:46 <highvoltage> but...
18:56:58 <tumbleweed> I do think there's a chance here for volunteers
18:57:02 <highvoltage> we haven't figured out how to make it for 2 tracks yet so... fosdem /o\
18:57:08 <tumbleweed> this seems like it's high-profile enough that people would want to be involved
18:57:09 <highvoltage> (way out of my league for this)
18:57:12 <tumbleweed> and not that high-skilled
18:57:25 <olasd> +1
18:57:27 <tumbleweed> just need to be able to cut some video in an editor, boost audio, etc.
18:58:02 <paddatrapper> #info post-processing loop snippets is possibly a good avenue for volunteers
18:58:08 <paddatrapper> #topic DC20 Review - Grabber
18:58:15 <highvoltage> 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 <CarlFK> I would highly recomend pointing new people at Shotcut
18:59:13 <tumbleweed> so, grabber
18:59:17 <tumbleweed> everyone hated the VNC
18:59:22 <olasd> there were some access reliability issues with VNC
18:59:24 <tumbleweed> but almost every talk used it
18:59:29 <highvoltage> but especially highvoltage hated VNC
18:59:33 <olasd> but once you got in it worked okay
18:59:40 <olasd> I think?
18:59:40 <paddatrapper> #info VNC was difficult to use, but grabber was used a lot
18:59:56 <tumbleweed> seems we missed some training issues there
19:00:03 <tumbleweed> how to not bring up the firefox menu when it's fullscreen
19:00:12 <tumbleweed> I found myself explaining that to somebody on sunday
19:00:24 <highvoltage> 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 <tumbleweed> I would just reconnect until it worked
19:00:53 <tumbleweed> and/or kill the vnc server
19:00:56 <olasd> I couldn't ever make xtigervncviewer work under wayland
19:01:04 <olasd> it connected, but the display never refreshed
19:01:12 <olasd> even though I could see my actions in voctoweb
19:01:15 <tumbleweed> that happened sometimes under X11
19:01:26 <olasd> yeah, but it happened everytime in xwayland
19:01:27 <olasd> :D
19:01:28 <paddatrapper> we may need to develop a remote-control-of-pad thing that we can drive from a browser
19:01:30 <tumbleweed> maybe half the time
19:01:44 <paddatrapper> and just avoid VNC completely
19:01:47 <highvoltage> perhaps looking into a spice server might be nice for another time where we need remote desktop access?
19:01:55 <tumbleweed> we tried
19:01:57 <tumbleweed> it suuuuuucked
19:02:07 <highvoltage> paddatrapper: +1 on remote controlling a pad potentially
19:02:12 <highvoltage> awh pity
19:02:25 <tumbleweed> people did use the pad differently to what I expected
19:02:34 <tumbleweed> I was assuming questions would be asked on IRC
19:02:47 <highvoltage> RDP then? (I think xrdp also relies on X at least on the other side, but at least it's efficient)
19:02:48 <tumbleweed> and the talkmeister would collate & summarise in thepad
19:03:03 <tumbleweed> highvoltage: I don't think efficiency was the problem
19:03:03 <olasd> tumbleweed: yeah, people just ended up cutting out the middle-talkmeister
19:03:07 <tumbleweed> this seemed like a bug
19:03:13 <olasd> which worked great, actually
19:03:22 <highvoltage> 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 <tumbleweed> and some non-talkmeisters took on that collation & organisation role
19:03:37 <paddatrapper> #info potentially look into controlling the displayed section of the pad remotely to avoid needing VNC
19:03:50 <highvoltage> no matter the stack, it helps when there are people around to pick up the slack
19:03:51 <pollo> yeah I tried spice, no go
19:03:56 <highvoltage> (you know it's true because it rhymes)
19:04:31 <paddatrapper> anything else on the grabber?
19:04:51 <tumbleweed> would we have been better off with talkmeisters sharing their own browser window?
19:04:55 <tumbleweed> (in jitsi)
19:05:05 <tumbleweed> I guess many wouldn't have had machines capable of it
19:05:08 <olasd> the grabber was *crisp*
19:05:12 <highvoltage> as a speaker I would say -1
19:05:13 <paddatrapper> I think we'll run into issues with video quality and readability
19:05:18 <olasd> getting that through jitsi? ew.
19:05:55 <tumbleweed> OK, let's move on
19:05:56 <highvoltage> 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 <tumbleweed> highvoltage: yeah
19:06:20 <paddatrapper> #topic DC20 Review - Streaming
19:06:27 <paddatrapper> The RTMP streams worked well
19:06:32 <tumbleweed> except when they died
19:06:37 <paddatrapper> the low latency was very helpful
19:06:41 <paddatrapper> tumbleweed: yes, except then
19:06:44 <olasd> kicking the nginxes in the mornings helped
19:06:45 <highvoltage> they only died for me when people were restarting things afaict
19:07:02 <pollo> I had some issues, but reconnecting fixed it
19:07:04 <tumbleweed> what sort of things were people restarting?
19:07:06 <paddatrapper> also the lower-quality streams didn't seem to die as often as the higher-quality ones
19:07:11 <highvoltage> olasd: maybe that needs to be cron'd :)
19:07:26 <olasd> but, yeah, the rtmp mirrors were very sensitive to (what I suppose were) network glitches between hosts
19:07:48 <tumbleweed> that seems like something that colud be fixed with monitoring + automated fixing
19:07:53 <olasd> tumbleweed: I don't think people restarted things much
19:07:55 <olasd> and yes
19:08:00 <tumbleweed> olasd: right, that was my point
19:08:07 <olasd> yeah, I know
19:08:14 <tumbleweed> there were breakages that I couldn't attribute to any restarting
19:08:14 <olasd> just driving it further
19:08:15 <paddatrapper> #info the RTMP streams were very sensitive to network glitches between hosts
19:08:31 <olasd> I think nginx-rtmp has all the proper knobs to do the monitoring, we just need to Do It™
19:08:41 <paddatrapper> #info the issues could potentially be fixed with monitoring and automated fixing
19:08:45 <highvoltage> I did notice the rtmp streams lost time the longer I used them. like, initially the slide I saw in OBS would show in my local stream about half a second later, which is really fantastic considering my latency to europe. but after a day or so it crept up to multiple seconds until I restarted the stream
19:08:50 <tumbleweed> there were also issues where RTMP clients would end up broken
19:08:54 <tumbleweed> and need restarting
19:09:13 <tumbleweed> highvoltage: yeah, the client will increase buffering whenever the buffer gets low (at least sensible clients will)
19:09:59 <tumbleweed> So, on to HLS streams
19:10:07 <olasd> the main problem of the rtmp stack is that we need people watching it for a while to test things, but it's hard to test things while people are watching the streams
19:10:22 <highvoltage> tumbleweed: I'm sorry I said it was broken for multiple years, obviously that was not quite the case
19:10:25 <tumbleweed> they got some hate, because there were problems
19:10:45 <tumbleweed> highvoltage: then, the question is did we change something that made them more fragile?
19:10:49 <tumbleweed> and if so, we should revert it
19:10:58 <olasd> what are you talking about now?
19:11:01 <tumbleweed> HLS
19:11:06 <highvoltage> it did seem to switch resolutions more often than needed, I wonder if those thresholds are tunable settings
19:11:23 <tumbleweed> highvoltage: I think that's video.js's heuristics
19:11:35 <tumbleweed> we definitely used a newer version there
19:11:41 <tumbleweed> so, new bugs etc
19:11:48 <highvoltage> *nod* that should probably be an action
19:11:55 <pollo> did we know if many people used HLS in a dedicated client?
19:12:05 <highvoltage> (and check if there are pressure settings for switching)
19:12:09 <tumbleweed> pollo: I didn't mine the logs for that
19:12:11 <paddatrapper> highvoltage: you offering :P
19:12:21 <paddatrapper> s/:P/? :P
19:12:27 <highvoltage> paddatrapper: sure, but I can't commit to a timeline on that
19:12:29 <tumbleweed> (but the logs will tell us)
19:12:44 <pollo> if most people use video.js, "HLS bugs" can as well be "video.js" bug
19:12:52 <tumbleweed> most people would have, yes
19:13:05 <highvoltage> I had problems in VLC too but didn't pay enough attention to them or log them down properly
19:13:05 <paddatrapper> #action highvoltage to investigate HLS/Video.js tunable settings for switching resolutions
19:14:05 <paddatrapper> anything else?
19:14:27 <olasd> hls in video players is not the greatest experience
19:14:46 <tumbleweed> yeah, rtmp does make more sense there
19:14:51 <olasd> (for instance, mpv will poke all qualities to do its video / audio format detection before playing the first second)
19:15:05 <highvoltage> ouch
19:15:18 <tumbleweed> sounds reasonable enough
19:15:39 <olasd> except it needs a bunch of segments of each quality to do that
19:15:46 <highvoltage> reasonable for watch movies / tv shows... not so much for interactive live streams
19:15:51 <olasd> ^ that
19:15:52 <highvoltage> *watching
19:16:07 <olasd> we should look at shrinking the fragment length still
19:16:11 <olasd> maybe that'll help
19:16:19 <olasd> s/fragment/segment/
19:16:26 <olasd> anyway EOT for me
19:16:29 <paddatrapper> #info shrinking the HLS segment length may help
19:16:38 <olasd> thx
19:16:44 <highvoltage> is there any streaming method that can try to sync up again?
19:16:47 <tumbleweed> olasd: so, I played wit hthat
19:16:50 <tumbleweed> notes on the ticket
19:17:05 <highvoltage> (as in, if there's a stretch of time delay that it can compensate to slowly catch up again? I guess not)
19:17:40 <tumbleweed> highvoltage: generally the answer there is not to buffer
19:17:45 <tumbleweed> or to keep the buffer size small
19:18:10 <highvoltage> we could probably do that in a highly configurable web player, at least.
19:18:37 <tumbleweed> YT live streaming will let you play at 2x, sometimes
19:18:44 <olasd> video.js is highly configurable; we haven't bothered much yet
19:18:45 <tumbleweed> (to catch up)
19:18:59 <highvoltage> olasd: cool, I'll spend some time on it, probably before the next MDCO
19:19:01 <tumbleweed> but we don't expose catch-up timelines
19:19:02 <olasd> (it's basically a video player construction toolkit)
19:19:16 <olasd> (with somewhat sane defaults)
19:19:41 <tumbleweed> (and all the craziness that comes from being in the js ecosystem)
19:19:45 <highvoltage> time to move on?
19:19:46 <paddatrapper> #topic DC20 Review - Etherpad
19:20:02 <pollo> It worked well?
19:20:20 <highvoltage> yes, although visaully impaired people said that it had accessibility problems
19:20:25 <tumbleweed> gwolf: I see you left a comment saying yous hould have been able to view pads without salsa. That was possible with RO URLs
19:20:34 <tumbleweed> highvoltage: I thought etherpad was supposed to be better than gobby there?
19:20:36 <highvoltage> we™ should probably follow up with them and file some bugs upstream
19:20:47 <paddatrapper> #info etherpad worked well, though it has accessibility problems
19:20:56 <pollo> tumbleweed: there was no clear UI for that though
19:20:57 <highvoltage> tumbleweed: yes, although still has some problems (I didn't have a chance to catch up on the exact problems)
19:21:14 <paddatrapper> highvoltage: do we have explicit issues that we can raise upstream?
19:21:18 <highvoltage> DebConf is total information overload :)
19:21:26 <tumbleweed> yeah
19:21:31 <tumbleweed> pollo: on the menu of a pad
19:21:41 <olasd> etherpads still need to be archived and the archived copy linked in the wafer
19:21:45 <tumbleweed> yep
19:21:55 <pollo> Yes,  but as a user you got a link and needed to login to see anything
19:21:57 <paddatrapper> I have the script from VOC, but need to send it on
19:22:00 <olasd> (mentioning it for meeting completeness, I know you know)
19:22:01 <highvoltage> paddatrapper: I suggest that we reach out to the people who had problems and file the issues upstream, at this stage I don't know what the exact issues are
19:22:26 <paddatrapper> #action paddatrapper to send on the etherpad archive script
19:22:31 <paddatrapper> highvoltage: yeah
19:22:33 <highvoltage> also, the etherpads looked pretty nice with their default colours and a few people commented on that
19:23:11 <highvoltage> there's also an item on the pad for improvements that mention default content for the etherpad
19:23:30 <tumbleweed> which was fully customizeable
19:23:35 <highvoltage> "    [DONE] Add some hook to switch to the sponsors loop after a talk when a talk ends
19:23:38 <highvoltage> Set up standard etherpad template for creating the pads - remove the 'Welcome to Etherpad!' stuff and add relevant sections (talk title, questions, comments, etc)"
19:23:49 <highvoltage> (oops pasted an extra line)
19:23:58 <highvoltage> yeah always possible, except that we didn't
19:24:03 <paddatrapper> this is probably useful know we know what people were using the pad for
19:24:08 <highvoltage> maybe content team could own that next time
19:24:16 <highvoltage> yeah that too
19:24:42 <tumbleweed> we had a little too much on our plates
19:25:05 <highvoltage> having all the etherpads links available in advance from wafer was *great*
19:25:13 <paddatrapper> #info look getting the content team to draw up etherpad default content
19:25:46 <tumbleweed> we also needed better moderation tools than we had
19:26:06 <tumbleweed> my plan was to switch to a salsa group to control access to etherpad. But never did it because we seemed to be surviving
19:26:26 <olasd> there was a user blocklist, right?
19:26:28 <paddatrapper> though I think the owner dialog bubbles helped there
19:26:30 <olasd> (see, I learned!)
19:26:41 <highvoltage> :)
19:26:43 <tumbleweed> olasd: nope
19:26:50 <terceiro> is it possible to block a user while they are writing?
19:26:57 <highvoltage> olasd: practice makes perfect
19:27:09 <tumbleweed> to block users I had to get salsa to ban them (so they couldn't log in again)
19:27:17 <tumbleweed> and kill their session from etherpad by deleting the session DB row
19:27:26 <highvoltage> wow, didn't realise!
19:27:28 <paddatrapper> #info we needed better moderation tools - salsa group access for example
19:27:42 <tumbleweed> but we only had to do this once
19:27:44 <olasd> salsa group access sounds really tedious to set up
19:27:50 <tumbleweed> the other problematic user stopped when asked
19:27:56 <olasd> (setting up group membership, I mean)
19:27:58 <paddatrapper> a group for blocking access would be nice
19:28:01 <tumbleweed> olasd: yep
19:28:26 <tumbleweed> but... next time not etherpad, presumably :)
19:28:32 <tumbleweed> so, whole new sets of problems
19:28:59 <highvoltage> what's the alternative to etherpad?
19:29:25 <tumbleweed> codimd was suggested
19:29:29 <highvoltage> if we don't use that then it might not be worth while to go through the excercise of finding accessibility bugs and filing them and rather do that for the next tool
19:30:00 <olasd> codimd is great, but I think etherpad was sufficient?
19:30:01 <paddatrapper> does someone want to volunteer to look at alternatives?
19:30:11 <tumbleweed> it was sufficient
19:30:29 <highvoltage> yep
19:30:32 <tumbleweed> the implementation of etherpad is far from pretty, though
19:30:51 <pollo> sticking with etherpad has the advantage of working on something we already know and tested
19:32:55 <paddatrapper> I think if someone wants to look at alternatives, they're welcome to. Until then we stick with Etherpad?
19:33:00 <olasd> sgtm
19:33:02 <highvoltage> +1
19:33:12 <paddatrapper> #agreed if someone wants to look at alternatives, they're welcome to. Until then we stick with Etherpad
19:33:23 <olasd> i've been meaning to look at codimd for other reasons but I won't commit for the video team :)
19:33:23 <paddatrapper> #topic DC20 Review - Audio
19:33:39 <highvoltage> this was probably the weakest area of the whole DebConf
19:34:15 <paddatrapper> #chair highvoltage olasd tumbleweed
19:34:15 <MeetBot> Current chairs: highvoltage olasd paddatrapper tumbleweed
19:34:20 <highvoltage> (especially bs1770gain during the first morning)
19:34:25 <paddatrapper> I'll be back in 3 minutes
19:34:48 <olasd> I'm not sure audio as a standalone topic makes sense
19:34:55 <pollo> +1
19:35:02 <olasd> we've had different issues with audio that were totally unrelated to one another
19:35:20 <highvoltage> I also think we've covered a sufficient number of audio topics already, and know that we need a new solution for audio normalization
19:35:28 <highvoltage> shall we move on?
19:35:32 <tumbleweed> well, compression could be the answer to a bunch of those issues
19:35:41 <tumbleweed> e.g. compressing jitsi and recording input
19:36:02 <olasd> #info compression could be a solution to a lot of audio issues we've had during the conf (jitsi levels, pre-recording levels)
19:36:05 <tumbleweed> gstreamer has a compression plugin (ladspa-dyson-compress-1403-so-dysoncompress)
19:36:15 <highvoltage> ah TIL, nice
19:36:23 <highvoltage> so we might need some gstreamer in the stack
19:36:26 <tumbleweed> not sure if FFMPEG has a built-in compressor
19:36:30 <olasd> all the stack is gstreamer
19:36:31 <tumbleweed> we have lots of gstreamer in the stack
19:36:37 <highvoltage> ah cool
19:36:40 <tumbleweed> not quite all
19:36:50 <olasd> all the core stack is gstreamer ;p
19:36:50 <tumbleweed> the jitsi -> voctomix isn't gstreamer
19:37:03 <olasd> ok, that's fair
19:37:03 <tumbleweed> just about everything else is :)
19:37:20 <pollo> jitsi does its own audio compression/normalisation thing
19:37:22 <olasd> #info gstreamer has a compression plugin (ladspa-dyson-compress-1403-so-dysoncompress)
19:37:26 * fil sneaks in and reads backlog
19:37:28 <olasd> pollo: poorly
19:37:44 <pollo> yes, but I think we'd need to disable those options
19:37:46 <tumbleweed> yes, of course ffmpeg has one (-af acompressor)
19:37:51 <highvoltage> I see gstreamer has an rgvolume and replaygain plugin too
19:38:00 <highvoltage> anyone familiar with that or tried it?
19:38:25 <olasd> replaygain is just about setting a gain equal to a bit of video metadata
19:38:58 <olasd> (so you need to analyse the source to know what gain to set, and record that in the metadata)
19:38:59 <tumbleweed> using an approach like replaygain can work (e.g. tag ingested files with their max level, adjust volume on playback appropriately)
19:39:06 <tumbleweed> but that only does normalization, not compression
19:39:13 <olasd> *nod*
19:39:15 <tumbleweed> so, it assumes that audio was well mixed to begin with
19:39:23 <olasd> which it wasn't, generally
19:39:24 <highvoltage> ah I assumed you could chain these
19:40:10 <olasd> you can, but they're two different things (normalization = making sure the max level is your target; compression = making sure your level is steady)
19:40:13 <tumbleweed> I could imagine expossing a compression control in voctogui
19:40:16 <tumbleweed> s/gui/web/
19:40:20 <olasd> using the latter would make the former less relevant
19:40:36 <highvoltage> cool
19:40:47 <tumbleweed> for playback at least
19:40:57 <tumbleweed> jitsi would probably have to be a hardcoded compressor in the ffmpeg pipe
19:41:01 <olasd> ack
19:41:13 <highvoltage> I suggest that we revisit this later in the interest of time
19:41:14 <olasd> which would need real-life tuning
19:41:20 <tumbleweed> yeah
19:41:29 <olasd> because compressing can do wonky stuff
19:41:40 <olasd> shall we move on?
19:41:41 <highvoltage> #topic DC20 Review - SReview
19:41:42 <tumbleweed> #agreed we should implement (configurable) compression in voctoweb playback
19:41:49 <highvoltage> #undo
19:41:49 <MeetBot> Removing item from minutes: <MeetBot.items.Agreed object at 0x11b1c90>
19:41:56 <highvoltage> oops
19:41:57 <olasd> #undo
19:41:57 <MeetBot> Removing item from minutes: <MeetBot.items.Topic object at 0x14e2f50>
19:41:58 <CarlFK> if someone will give me read access to a bunch of videos, I'll show off some visualization that lets you look at a 30 min video and have a good guess about audio level quality
19:42:01 <olasd> #agreed we should implement (configurable) compression in voctoweb playback
19:42:05 <highvoltage> #topic DC20 Review - SReview
19:42:05 <CarlFK> (previous topic)
19:42:44 <tumbleweed> it's hard to have a good discussion here without wouter
19:42:46 <highvoltage> do we need wouter for this?
19:42:49 <highvoltage> ack
19:42:58 <tumbleweed> I suspect there are some bus-factor questions that don't need him
19:43:22 <tumbleweed> e.g. is sreview working for us with bus-factor of 1, or do we need to get more people involved / look at other options
19:43:42 <tumbleweed> I doubt anyone would disagree that more people involved would be better
19:43:47 <olasd> it's certainly been the stickiest point during this debconf
19:44:05 <tumbleweed> personally, I don't think the stickyness there is sreview itself
19:44:12 <highvoltage> the upload acknowledgement could do with a bit more css/html... and vocabulary
19:44:24 <tumbleweed> highvoltage: I think he plans to pull that stuff out entirely
19:44:28 <highvoltage> ah
19:44:31 <tumbleweed> also, apparently that exists, it just isn't working as expected
19:44:34 <olasd> tumbleweed: no, that's true, it's an issue of... knowledge
19:44:44 <tumbleweed> there are also handover issues
19:44:50 <olasd> (of the system and how it works, and how to fix it when it doesn't)
19:45:13 <tumbleweed> e.g. we're all shrugging, not knowing what the state of the videos is, yet
19:45:23 <tumbleweed> we could be tackling these as a team
19:45:25 <tumbleweed> but we're not
19:45:54 <highvoltage> sounds like we need a collective session with wouter?
19:45:58 <tumbleweed> to some degree, one learns how the system works in the heat of battle
19:46:03 <tumbleweed> I know I did :P
19:46:17 <highvoltage> I actually admire our collective ability to hotfix *anything*
19:46:35 <pollo> tumbleweed: I did put a great amount of energy reviewing videos during the conf
19:46:41 <pollo> and mostly had to do it a second time
19:46:50 <tumbleweed> :/
19:46:55 <tumbleweed> yeah, I started a big round of final review
19:47:00 <tumbleweed> and then found that they weren't final
19:47:08 <tumbleweed> so, ... stopped
19:47:22 <tumbleweed> that is part of the point of that review, to find problems and address them
19:47:47 <tumbleweed> but it's also demotivating when you don't really know what's going on
19:47:56 <paddatrapper> +1
19:48:00 <highvoltage> that's pretty much my default setting
19:48:30 <olasd> a lot of stuff has been dealt with on the fly and could have used some documentation through the dc20 issue tracker
19:48:37 <olasd> so other would know what was going on
19:48:40 <olasd> others*
19:48:50 <highvoltage> so our on the fly communication could be better
19:49:01 <highvoltage> might be good to agree on some communication protocals ahead of the next event
19:49:04 <olasd> this is a more general remark than just sreview; and this is as much my fault as anyone else's
19:49:19 <tumbleweed> and we should probably write some low-level sreview documentation
19:49:24 <highvoltage> i.e. file issues here, make notes in this pad, mention on this channel when you restart this, etc
19:49:26 <olasd> when the event is spread across 12 timezones it's hard to read the backlog
19:49:49 <tumbleweed> separate channels could maybe help?
19:50:00 <tumbleweed> but pads + bugs sound better
19:50:02 <olasd> from experience, they don't
19:50:09 <highvoltage> +1 on pads + bugs
19:50:11 <olasd> because people never use the right one
19:50:24 <paddatrapper> Yeah pads and bugs sound better
19:50:26 <highvoltage> irc is better for live throwaway stuff that won't matter anymore 5 minutes later
19:50:52 <pollo> I'm not so sure about pads
19:51:04 <pollo> I never know which one is the right one
19:51:14 <pollo> and feel like we are duplicating the issue tracker
19:51:17 <highvoltage> exactly why we should agree on them in advance
19:51:21 <tumbleweed> a pad tracking here's the shit we've hacked up in sreview right now, would have been good
19:51:37 <tumbleweed> rather than shouting "PLEASE DON'T TOUCH" at each other
19:51:43 <highvoltage> :)
19:51:47 <terceiro> maybe a single issue tracker should work
19:51:57 <terceiro> for the entire operation during the conf
19:52:17 <terceiro> to track each incident individually
19:52:37 <tumbleweed> they were all a little intertwined
19:52:59 <highvoltage> pads are nice because they're ultra quick. no forms to submit, you don't have to flesh out all the details yet, it's nice for quick thoughts that can later be fleshed out in decent bug reports
19:53:31 <tumbleweed> yeah, more of a living document
19:54:04 <terceiro> true
19:54:23 <highvoltage> then again, if someone only wants to use the bugs and avoid a pad, I think that's actually fine too, as long as the information ends up logged at either location
19:54:25 <terceiro> my main point is, whatever tool you pick, pick a single location to take these notes
19:54:27 <paddatrapper> our end result should probably always be an issue in an issue tracker
19:54:36 <highvoltage> yeah
19:54:46 <paddatrapper> but a working document during the incident is helpful
19:54:59 <tumbleweed> I started one when I started hacking, but it didn't last long :(
19:55:12 <olasd> we've drifted away from sreview to more general topics I think
19:55:18 <tumbleweed> yep
19:56:35 <highvoltage> (how long is this silence going to last, can I go get some coffee?)
19:56:49 <tumbleweed> #topic Long Term Video setup for miniconferences
19:57:06 <tumbleweed> needs hosting
19:57:25 <paddatrapper> but conceptually I think it is a good idea
19:57:43 <tumbleweed> yeah
19:57:54 <olasd> sure
19:58:07 <paddatrapper> I'm happy to look into hosting options
19:58:13 <tumbleweed> The pt-br crowd are doing weekly video chats
19:58:19 <tumbleweed> it'd be great to be able to host them
19:58:32 <highvoltage> I'm working on hosting on a few fronts, combination of free and paid for, and even the debian openstack is miraculously moving forward (I might have more info on that this time tomorrow)
19:58:56 <paddatrapper> highvoltage: ok, then shall we coordinate your efforts and these?
19:59:02 <tumbleweed> unfortunately our current infra isn't exactly lightweight
19:59:08 <tumbleweed> mainly the voctomix bit
19:59:10 <highvoltage> paddatrapper: yeah let's work together on that
19:59:31 <tumbleweed> but I could imagine a long running jitsi + jibri -> stream setup
19:59:43 <paddatrapper> #action paddatrapper and highvoltage to work on hosting for permanent infra hosting for miniconfs, testing, etc
20:00:23 <highvoltage> obs also needs decent software accelleration. seems like the cirrus logic driver is used by default in openstack deployments because it needs miniscule amounts of ram to start up (as apposed to 16MB by the other virtual cards)
20:00:58 <tumbleweed> vfb any better?
20:01:10 <highvoltage> and obs crashes on cirrus, presumably either by missing instructions or too little video memory
20:01:17 <highvoltage> not sure, maybe worth a try
20:01:51 <tumbleweed> that's possibly what I was testing on before we got our GPU instance working
20:01:56 <tumbleweed> but the memory is fuzzy
20:02:00 <highvoltage> I noticed that the VPS's at hetzner uses the virtio for video, I intend to check at digitial ocean and vultr too fwiw just so that we have a list
20:02:54 <highvoltage> also... uhm...
20:03:50 <highvoltage> yeah the excitement about minidebconfs is uncontainable and it seems that there might be a lot of them happening towards the end of the year
20:04:21 <olasd> we need a strong volunteer base for that to happen
20:04:32 <highvoltage> probably a good target to try out some different stuff. and not sure how much we could even have DebConf video team involved for all of that
20:04:55 <highvoltage> my thought is that training will be really important and that we'd have to get every team to be more or less basically autonomous
20:05:33 <paddatrapper> I think We do have another topic for the minidebconfs. Shall we move to that?
20:05:34 <highvoltage> (I mean, I don't mind at all being somewhat available to restart something here and ther if it comes to it, but for the day to day volunteering and stuff I think that should be completely self contained)
20:05:42 <highvoltage> oh sure
20:05:45 <olasd> paddatrapper: yes
20:05:52 <paddatrapper> #topic Upcoming MiniDebConfs
20:05:55 <highvoltage> (I missed there was another item)
20:06:14 <olasd> #info the excitement about minidebconfs is uncontainable and it seems that there might be a lot of them happening towards the end of the year
20:06:19 <tumbleweed> :P
20:06:26 <highvoltage> so far there is "MDCO Gaming edition" 21+22 November
20:06:32 <paddatrapper> planning doc: http://deb.li/i4Y5M
20:06:37 <highvoltage> "MDCO Brasil" 28+29  November
20:06:39 <olasd> I had to put it in verbatim
20:06:49 <highvoltage> MDCO India 5+6 December
20:06:57 <highvoltage> which are all in that planning doc
20:07:39 <highvoltage> and also a Spanish one probably across regions that there isn't much detail for
20:07:41 <olasd> so my main concern here is the expectation that core video team members would be available over three subsequent week-ends
20:07:55 <olasd> I understand that's not what's being asked of us, which is good
20:08:26 <tumbleweed> it'll need at least some core video team people available, though
20:08:37 <highvoltage> we can perhaps try to change dates so that it's more spread out, which risks getting closer into holiday season or closer ot now
20:09:41 <paddatrapper> maybe we need to poll the core team and find who is keen and available? If there are not enough of us, then look at changing dates?
20:10:04 <tumbleweed> I'm presumably still not going to be working, so can have energy on weekends. But can't commit to any particular timezone at this point
20:10:07 <olasd> I've ended up having to look at things on most mornings during this debconf and I'd rather have that not happen again over the course of three weekends, to put it more pluntly
20:10:10 <highvoltage> I'm not going to actively watch all the talks that I can't understand but I don't mind being available for all of them to restart things that fail, not sure to what level more than that would be needed
20:10:18 <olasd> bluntly*
20:10:48 <paddatrapper> I'm available Saturdays usually, but my Sundays are already spoken for
20:10:53 <highvoltage> olasd: I guess if you could even be available for one of those weekends, it would be fine
20:11:54 <highvoltage> saturdays are probably also likely to be the most intense as people (as in, new directors) are getting the hang of things
20:12:24 <highvoltage> but, we can also use every event as a little bit of a training ground for the next
20:12:28 <olasd> highvoltage: sure, I'd love for us to be able to be in a state where that's true; but I don't think we can /commit/ to that right now (i.e. I think this is too ambitious)
20:12:53 <tumbleweed> I see these as 4 almost completely separate communities
20:13:00 <tumbleweed> I doubt there'll be much volunteer overlap
20:13:28 <pollo> Training in itself takes a lot of energy
20:13:37 <nattie> but is useful in the longer term, hopefully
20:14:00 <highvoltage> tumbleweed: in DebConf we usually bring the next DC team to the current one, at least the gaming edition is in a language that's mostly common, maybe we could get people from all those teams to do some directing there
20:14:13 <tumbleweed> highvoltage: that'd be a good goal
20:14:26 <tumbleweed> we try. But we also fail a lot at actually getting them involved :)
20:14:30 <highvoltage> it could even be a requirement.
20:14:47 <olasd> it was a requirement during this debconf
20:14:50 <phls> I would like to reproduce all the solution to be able to setup everything and use you as a "N2" support for us
20:14:51 <olasd> it worked... sort of
20:15:10 <tumbleweed> the miniconfs are probably what's responsible for it working
20:15:14 <olasd> anyway, I've voiced my concerns; I'm happy to work towards getting these teams involved so they're mostly autonomous
20:15:18 <tumbleweed> (language tracks)
20:15:24 <highvoltage> well this debconf was also rough for a lot of the reasons we listed above
20:15:27 <olasd> but I think getting that done before november is a pipe dream
20:16:01 <tumbleweed> I think we're comfortable with using a lot of our stack for november (not needing to build new things)
20:16:10 <tumbleweed> until we get to the sreview bits
20:16:34 <highvoltage> it might be a good time to experiment with some small bits but yeah I don't think it's the place for major changes
20:16:49 <paddatrapper> the biggest issue I see for the miniconfs is the sreview parts
20:16:56 <olasd> tumbleweed: yeah, as long as not all three weekends start at 10:00 UTC
20:16:58 <tumbleweed> I don't think there'll be the energy for anything but small bits :)
20:17:03 <highvoltage> I admit that's a major hole in the plan
20:17:14 <highvoltage> (the sreview part)
20:17:21 <olasd> (I'm sure the brazil minidc won't start at 10:00 UTC :P)
20:18:03 <tumbleweed> it would be a good time to experiment with other approaches before sreview's next big conference, if wouter had the energy to do that (no idea)
20:18:24 <highvoltage> *nod* needs some follow-up with wouter
20:18:27 <olasd> :)
20:19:12 <phls> olasd, probably 10h but UTC-3 :-)
20:19:35 <olasd> :)
20:19:50 <nattie> that's a lot more civilised!
20:20:05 <highvoltage> so about 15:00 for a lot of us in this channel. that's about 2 hours after I got up this afternoon. great!
20:20:32 <olasd> #link http://deb.li/i4Y5M
20:20:49 <gwolf> tumbleweed: FWIW we didn't publicize enough the RO URLs (for getting to the pad without salsa)
20:20:56 <gwolf> I never heard of them, at least
20:20:59 <tumbleweed> gwolf: we didn't, yeah
20:21:03 <gwolf> (yes, I'm hard of hearing...)
20:21:13 <tumbleweed> we decided not to bother exposing them in wafer, because too much work
20:21:46 <olasd> should we #agree on something and move on?
20:22:06 <tumbleweed> yes, please :)
20:22:09 <highvoltage> we agree that all the minidebconfs will be crazy but I think it's going to be ok
20:22:19 <phls> what worked to me at MiniDebConf Brussels was watch olasd setup a machine, and after try to reproduce it by myself. And asking to him when I dind't know something
20:22:43 <phls> *MiniDebCamp
20:23:34 <paddatrapper> #agree that minidebconfs need to have their own volunteers
20:23:51 <tumbleweed> phls: that helps you to understand a little bit about how things are set up
20:24:06 <olasd> #agree video team will provide training to minidebconf volunteers, and basic infra
20:24:10 <tumbleweed> but I don't think it teaches you how to troubleshoot the problems that arise during the conference
20:24:27 <olasd> actual role distribution TBD
20:24:46 <phls> tumbleweed, yes, in this case, I believe it will be important work together on MDCO gaming before
20:25:15 <paddatrapper> any other #agrees needed?
20:25:18 <tumbleweed> yeah, some training may be possible there
20:25:22 <olasd> tumbleweed: troubleshooting checklist = reboot the servers one by one until things work
20:25:27 <paddatrapper> or shall we move on?
20:25:33 <olasd> let's go
20:25:43 <paddatrapper> #topic Blog post / some sharing about videostack during this DebConf
20:25:57 <highvoltage> I added this entry because I wasn't sure if anyone was working on this
20:25:57 <olasd> we skipped the hls topic
20:26:08 <highvoltage> didn't we cover it enough?
20:26:17 <paddatrapper> olasd: we dealt with it during Streaming didn't we?
20:26:49 <highvoltage> it basically comes down to further research into tunables for the web player and shrinking segments in nginx if possible
20:26:54 <olasd> I have no idea what that was about
20:26:59 <olasd> ok then
20:27:24 <highvoltage> so pollo has done some blog entries in the past, not sure if he is this time or if we should perhaps work on one collectively somewhere?
20:27:41 <highvoltage> I think that there was enough new and exciting things to talk about and that we should share
20:28:09 <paddatrapper> There were also a few people asking about our setup, so having something to point people to would be nice
20:28:33 <pollo> Why blog post and not document it properly in sphinx?
20:29:07 <highvoltage> sphinx documents don't read that well on planet Debian, but yes the documentation parts should be in spinx
20:29:16 <paddatrapper> I think for me, we have things documented, but that doesn't highlight what was added to get everything work
20:29:29 <tumbleweed> and/or we should give a talk about it
20:30:21 <highvoltage> do you think nattie has learned enough portuguese yet so that she can present it at the portuguese MDCO?
20:30:33 <highvoltage> (I'm 52% joking, of course)
20:31:25 <paddatrapper> maybe during MDCO#2 Gaming?
20:31:33 <highvoltage> yeah a talk or even a lightning talk would be nice, but I like the idea of a blog post. I guess I could just tack on some of it in my next DC20 blog post if there's not particular interest for that
20:31:54 <paddatrapper> I am happy to take a stab at it too
20:32:29 <highvoltage> pollo: also something like "malayalam characters lead to improved internationalization in sreview" is an interesting thing that happened but probably doesn't have much space in the documentation
20:32:51 <highvoltage> paddatrapper: shall we do that in an etherpad?
20:33:04 <paddatrapper> #action paddatrapper and highvoltage to flesh out a blog post
20:33:08 <paddatrapper> highvoltage: good idea
20:34:57 <paddatrapper> anything else here?
20:35:05 <pollo> This meeting has been going for more than 2h30 now and I don't have a brain anymore
20:35:17 <olasd> ^ this
20:35:20 <tumbleweed> yeah, lunch time pls
20:35:21 <highvoltage> when in doubt move forward :)
20:35:23 <paddatrapper> #topic Next meeting
20:35:40 <paddatrapper> Thursday 10 September 2020 @ 18:00 UTC?
20:35:54 <olasd> do we need to stay weekly?
20:36:01 <highvoltage> it's soon but since there are still loose ends for DC20, wfm
20:36:17 <olasd> should we do a poll to get some new people involved with a new time slot?
20:36:27 <paddatrapper> yeah, let's do that
20:36:32 <olasd> or at least... try?
20:36:39 <olasd> (I know rwalborn was keen)
20:36:43 <paddatrapper> #action paddatrapper to poll for a new meeting day and time
20:36:48 <highvoltage> might be nice to have some more people from India for a few of these
20:36:59 <highvoltage> especially approaching MDCO season
20:37:07 <paddatrapper> #endmeeting