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/
Attachment:
signature.asc
Description: PGP signature