Hey Wookey! This was "Re: Debconf20 will be in...". Moving the thread to debconf-video :D 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?) Maybe some other members of the DebConf Videoteam can chime in to correct me if I'm wrong, but: 1. At most DebConfs, we are dependent on the existing networking infrastructure. The stack the venues run inevitably creates overheads. 2. Having video at all at DebConfs is already quite a feat. We often get the rooms very little time in advance and prefer to focus our energy into making sure the sound is good and that videos are mixed, recorded and streamed somewhere. That doesn't mean we don't care about creating a better experience for remote attendees, but we're already struggling to make the current stack work. Any new solution needs either to decrease the current work to bring up the stack or at least to not have any impacts on it. 3. Some of the delay is attributable to our live video mixing setup that uses voctomix and gstreamer. Voctomix needs quite beefy machines to run and processing three inputs (2 cameras + speaker's laptop) isn't an easy task. Often, we struggle to find machines as powerful as we'd like. 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. If you want to have a look at voctomix's performance, I'm sure a lot of people would benefit from it. I guess [1] would be a good place to start. 4. Our streaming setup is documented here [2]. As you can see, we are using a local streaming frontend and multiple geolocated mirrors for performance reasons. Nicolas knows better, but this is bound to create delays. We are also processing the videos with FFMPEG to downsample them, as some remote attendees don't always have a very good internet connection. Again, more delays. Finally, we are using buffers to make the videos watchable. Without buffers, streamed videos can get choppy. Again, not an expert on this, but maybe something in our nginx-rtmp configuration could be tweaked? If you want to have a look at it, it's all here [3] and here [4]. > 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]. 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]. 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 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. Cheers! [1] https://github.com/voc/voctomix/issues/38 [2] https://debconf-video-team.pages.debian.net/docs/streaming.html [3] https://salsa.debian.org/debconf-video-team/ansible/tree/master/roles/streaming-backend [4] https://salsa.debian.org/debconf-video-team/ansible/tree/master/roles/streaming-frontend [5] https://debconf-video-team.pages.debian.net/docs/room_setup.html#audio [6] https://salsa.debian.org/debconf-video-team/ansible/issues -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org ⠈⠳⣄
Attachment:
signature.asc
Description: OpenPGP digital signature