Re: Prepare for more online participation?
On 2020-03-25 09:07 +0100, Wouter Verhelst wrote: > Hi folks, > > I think we should prepare ourselves for the likelihood that, given the > current pandemic, ... this > year's DebConf will require more online participation, or in the worst > case be an online-only debconf. > We did run an experiment for a streaming-only event last year for Ben's > talk, and I think that was a success. If there will still be some > attendance, then we can reuse the method used last year in greater > numbers. However, I think we should also look in some detail towards > free software videoconferencing solutions. I recently learned that > Jitsi[1] has the ability to stream to YouTube; Yeah I discovered that a couple of days ago too. Presumably it can/could also stream to free things like our current vlc setup. > Jitsi really only > requires a webbrowser, has support for screen sharing, and is at least > working on a presenter mode[2][3], so this should theoretically be a > good match. I should note, however, that I haven't looked at things in > detail yet. I like jitsi-meet - it works well, and I've used the free instance up to 15 people and it's worked surprisingly well. On the other hand the design is for the server to not do much and send all the streams which has scaling limitations. As you say, the one thing missing from jitsi for conference use is being able to record the presenter (but perhaps that could be a separate thing?), and being able to send both slides and video. Glad to see that they are working on that. I'm interested in this subject generally for better remote attendance at our conferences. I think we can do better than the current 30-sec delayed stream and IRC incoming, and have had some discussions about it (copied to this list) but not done anything useful. This is of course a slightly different problem from an entirely remote conference. Suse made a thing based on libjanus which seems like it might be a good project to work from: https://en.opensuse.org/Portal:Jangouts I have so far merely discovered its existence (after the libjanus talk at FOSDEM this year), but have not checked it out. The two free 'conference' platforms that seem to have some momentum are apache openmeeting and bigbluebutton. I have tried neither. And there is a moodle plugin to do similar things. These seem to be more focussed on education and I presume have a server-side mixing architecture? > It would seem that we have a lot to explore if we're going to do this; > but given that DebConf20 is still a ways off, if we get started now we > should have the necessary time to get everything ready in time. > > Thoughts? Good plan. It would be good to come up with a non-proprietary alternative to zoom, which is currently taking over the world, and that's unfortunate. (although they have now made that work in just a browser. Rather than a local install so its 'only' a pile of proprietary javascript, like everything else...) I'm happy to help out with testing but have negligible actual expertise in this area. (I'm currently in the middle of a 2-day zoom+youtube streaming remote conference which is actually working reasonably well without installing any non-free stuff except all the stuff delivered on the page. That only allows questions by chat, not in person, but is a perfectly good experience, and if we could achieve the same level I would could that as a success.) We should start out with some evaluation of the available tech, and a think about an architecture that would work for 400 people. jisti+streaming server could work so long as most participants are only on the stream, with a few uploaders that want to speak. I'm not sure how possible/practical that is. And testing with large numbers is always hard of course. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Reducing streaming latency
On 2019-03-21 08:23 +, Andy Simpkins wrote: > Hi Wookey, > > Presently each talk room has a dedicated IRC channel and we try and take > questions from IRC, typically a member of the video team will simply ask the > question on your behalf. Right, but if you've tried to use this you'll know that it often doesn't work very well in practice unless you have a 'stooge' monitoring the IRC and interjecting on your behalf. IRC can easily not be noticed at all, and even if it is tends to get lower priority than people in the room. And this 'being there in person priority' is actually the main thing I think we should try to address. If we are to significantly reduce extremely high-carbon long-distance travel to conferences, we have to make remote attendence work as well as being there, not be a massive disadvanatge, or otherwise highly unsatisfactory, or as close as we can get to that. > Reading between the lines you would like to remotely partake in Debconfs in a > more interactive manor, be able to ask questions etc. and you see the latency > of the video stream as a problem to this. Correct. This is especially true for BOFs. But just being 30-seconds behind the thread in the room (made worse by not knowing how long/realising that you are delayed) is a real problem for responding to points or adding info. > Does this mean that you want to interrupt the presentation, shout out your > comment / question part way through? We try and discourage that from in a > talk > room and certainly do not want to open that up to the internet at large :-p No, in exactly the same way as you don't do it in the middle of a presentation when sat in the room, even though you could. What matters is people (both in the room and remotely) being able to see that you are in attendance, and to be able to interject/ask to be recognised, on an equal(ish) basis to people in the room. That is where we should be trying to get to. Andy and I discussed this in some detail in the pub yeterday and reached some conclusions about a) how something better could work and b) practical things to try. We (mostly he :-) will write those up as a proposal for discussion to this list. I've now joined this list. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Reducing streaming latency
On 2019-03-20 18:39 -0400, Louis-Philippe Véronneau wrote: > Hey Wookey! Hi - thanks for taking an interest. > On 19-03-20 17 h 44, Wookey wrote: > > We were well ahead of the trend in videoing all talks+questions > > effectively. I think we should see what we can do to use technology to > > make effective remote interaction work. Currently there is too much > > lag on outgoing video (~30seconds?) > > IIRC, the feed out of voctomix easily has a good 3-5 seconds delay already. > > If you can point us to other projects using a voctomix stack (CCC VOC, > LCA, etc.) that have worked on latency issues, it would be a nice > pointer for us. I don't have any direct experience here. When I say 'technology experience' what I mean is that I've tried to attend quite a lot of conferences remotely with varying degrees of success, using Debian's set up, Ubuntu's set-up, hangouts, some proprietary conference-in-browser software, and 3 different types of telepresence bot. So I have some idea of what the issues are. There are more issues than solutions at the moment :-) [snip much technical detail] Yes I agree what we have makes sense for what we currently try to achieve, and that none of this is simple, but if we changed the emphasis from 'making uploadable video which can also be watched live-ish' to 'must enable n-way discussion with some remote participants' then we'd make different tech choices. Ideally we'd have a load of bots too, so one can partake of the often-more-important hallway track, but that involves hardware and a different set of problems from just making the talks/BOFs remote-interactive. It does solve both problems so is worth thinking about, but they don't do stairs or lifts, and ones that actually work well are expensive and heavy. In my experience availability is highly regional too (USA and Paris only so far, but maybe there is an Israeli company that would like to help out...). Bots also have some interesting cultural issues (it's still quite 'wierd', even for geeks), although familiarity could fix that. > > and no incoming video/audio, so it's pretty-much broadcast-only. > > I don't have a good solution to this. If you can point us to something > that's easy to implement and that does not require tons of extra gear or > a shitton more work to setup, I'm sure we would be interested. Our > current audio schemas can be found here [5]. This is a big question and I don't have direct answers, but given the ubiquity of RTC video/audio meetings, I think we ought to be able to use that tech in debconf. So something like jitmeet integrated into the set-up so that someone could appear on-screen when asking a question, and get near-enough real-time video, ought to be possible. Perhaps a second screen with all the remote heads on (more or less like the old Ubuntu IRC screen), zooming in to a speaking head, would work. It may be easiest not to try to integrate this into the existing high-quality stream/recording, but to have a parallel real-time/interactive RTC setup for people who wish to follow/interact live? > If you want to follow-up on any of this, I think the best thing to do > would be to create a new issue on our bug tracker [6]. OK, that seems sensible. I'll do that. > Again, it's not that we don't care, more that we don't have enough time > to do everything we would like to :D Of course. I need to do some traffic simulations for an argument about bike-friendly roundabouts tomorrow and it's nearly 2am already :-) > As you can see, everything we do (docs, code, etc.) is on Salsa, so feel > free to tinker and send us patches if you have some spare time. Well. I think we need a conceptual discussion to try and work out something that might do the job for a sane amount of effort first. Patches later :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
