Re: Reducing streaming latency

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. It is also not uncommon for other attendees to stand up and ask questions from IRC either. In a popular talk with lots of questions I agree we tend to prioritise questions from within the talk-room, it is not uncommon for a talk session to end with questions left unanswered. Occasional we do not have enough volunteers to cover all the video team requirements so things like IRC do get missed because it is not our highest priority, I accept 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.

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

On 21 March 2019 01:57:25 GMT, Wookey <wookey@wookware.org> wrote:

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